From andy@netconfcentral.org Thu Mar 1 00:36:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08F21F85D7 for ; Thu, 1 Mar 2012 00:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDeEgA2y6QYx for ; Thu, 1 Mar 2012 00:36:32 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id B39DE21F85D4 for ; Thu, 1 Mar 2012 00:36:32 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q218aVEU027387 for ; Thu, 1 Mar 2012 03:36:32 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48174] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 88/D0-29124-F053F4F4; Thu, 01 Mar 2012 03:36:31 -0500 Message-ID: <4F4F351A.703@netconfcentral.org> Date: Thu, 01 Mar 2012 00:36:42 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: NETMOD Working Group References: <4F4E9559.2000008@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 08:36:34 -0000 On 02/29/2012 11:59 PM, Ladislav Lhotka wrote: > On Wed, 29 Feb 2012 13:15:05 -0800, Andy Bierman wrote: >> Hi, >> I will let implementors vote with their feet. If anyone implements this data model, then that shows that it is usable just fine and my concerns are unfounded. I don't agree that unique-stmt in YANG allows list or leaf-list. I think RFC 6020 is vague on the details. It certainly does not work if there is more than 1 node in the tuple. The text does not call out the special case where the tuple has only 1 schema-node in it. Andy >> I was trying to update the modules on netconfcentral.org, and yangdump >> is complaining about ietf-routing.yang. 1 fatal error and some warnings. >> >> unique "interfaces/interface/name"; >> >> Error: list node (interface) within unique stmt 'interfaces/interface/name' for node 'interfaces/interface/name' >> ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node >> >> >> A unique-stmt for container/list/leaf is not allowed. Only container and leaf are allowed. >> RFC 6020 may not be clear on this. Martin should fix it ;-) > > I did check the spec before writing that statement, and it doesn't seem to exclude this case. > The use case is clear: partition the list of logical interfaces into sublists and make sure the sublists are disjoint. > >> >> It can work if there is only 1 node in the 'uniqueness tuple and only 1 list in the path. >> But except for that special case, list cannot deterministically produce a set of instances >> that belong to the same tuple, for comparison to another tuple. > > I think it is a matter of definition, and IMO a reasonable definition is in RFC 6110, sec. 12.16. Of course, I could change the 'unique' statement into 'must' along these lines but that would be much less readable. > >> >> If I comment out the unique-stmt, then I get these warnings from ipv4 and ipv6 modules: >> >> Warning: sibling object 'address' already defined in module 'ietf-ipv4-unicast-routing' at line 85 >> ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate sibling node name from external augment >> >> Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 >> ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment >> >> Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 >> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment >> >> Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 >> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment >> >> Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 >> ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment >> >> Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 >> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment >> >> Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 >> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment >> >> These warnings are because each module does an external augment on >> the same target, using the same 'route-content' grouping. So all siblings >> have duplicate local-names in different namespaces. > > I don't see it as a problem. We have next-hop for both IPv4 and for IPv6, named v4ur:next-hop and v6ur:next-hop. Moreover, the augments are conditional so that these two can never become siblings - in fact, they cannot be in the same routing table. > >> >> I really think it sets a bad precedent to intentionally cause local-name >> collisions -- to be as XML namespace dependent as possible. > > For me namespaces is one of the few reasons for using XML rather than, e.g., JSON. > >> The user-friendly thing to do would be to always add your own sub-container. > > With subcontainers you cannot use leafrefs effectively. That's why we have a flat list of interfaces. > >> This is how CLI keeps things straight. E.g.: >> (note container insertion before 'uses route-content') >> > > Each 'routing-table' already has 'address-family' and 'safi' as its children, so it makes little sense to carry the redundant address family information in each route: > > > ipV6 > nlri-unicast > > > > ... > > > ... > > ... > > > With 250K routes this can already make a difference. > > Lada > >> >> augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >> + "rt:routes/rt:route" { >> when "../../rt:address-family='ipV4' and " >> + "../../rt:safi='nlri-unicast'" { >> description >> "This augment is valid only for IPv4 unicast."; >> } >> description >> "This augment defines the content of IPv4 unicast routes."; >> >> container ipv4-unicast { >> uses route-content; >> } >> } >> >> augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >> + "rt:routes/rt:route" { >> when "../../rt:address-family='ipV6' and " >> + "../../rt:safi='nlri-unicast'" { >> description >> "This augment is valid only for IPv6 unicast."; >> } >> description >> "This augment defines the content of IPv6 unicast routes."; >> container ipv6-unicast { >> uses route-content; >> } >> } >> } >> >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Thu Mar 1 00:47:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D321F862B for ; Thu, 1 Mar 2012 00:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6GZFrT36WwM for ; Thu, 1 Mar 2012 00:47:45 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E321F85DA for ; Thu, 1 Mar 2012 00:47:44 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id B14072A276D; Thu, 1 Mar 2012 09:47:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330591663; bh=Ywa/3a6YpBdjEmdazybOGLIsYqDIoRbi8FlNTsm5N5w=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lc/UFkA5G8htGg9U8W/Cfyl2aoOW4XM4333jWUpO42tp2ifzHHMfbmGoKtKHDKOB4 NwZDeFPQuiM/RrOz3FKuolb6bv/jnSWIuCV+XpYa3BlaDXnbUQOdu3obIDv0M1F8tI VUXAu0ZnSj1fBRUNEzfewm6CXWGPo1pJYltnDqnQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F4F351A.703@netconfcentral.org> Date: Thu, 1 Mar 2012 09:47:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 08:47:46 -0000 On Mar 1, 2012, at 9:36 AM, Andy Bierman wrote: > On 02/29/2012 11:59 PM, Ladislav Lhotka wrote: >> On Wed, 29 Feb 2012 13:15:05 -0800, Andy = Bierman wrote: >>> Hi, >>>=20 >=20 >=20 > I will let implementors vote with their feet. > If anyone implements this data model, then that shows that it > is usable just fine and my concerns are unfounded. I am now working on such an implementation. :-) >=20 > I don't agree that unique-stmt in YANG allows list or leaf-list. > I think RFC 6020 is vague on the details. It certainly does not work > if there is more than 1 node in the tuple. The text does not call out The Schematron rule mapped from a 'unique' statement does work even for = multiple nodes in the tuple and IMO there is no ambiguity. Lada =20 > the special case where the tuple has only 1 schema-node in it. >=20 >=20 > Andy >=20 >>> I was trying to update the modules on netconfcentral.org, and = yangdump >>> is complaining about ietf-routing.yang. 1 fatal error and some = warnings. >>>=20 >>> unique "interfaces/interface/name"; >>>=20 >>> Error: list node (interface) within unique stmt = 'interfaces/interface/name' for node 'interfaces/interface/name' >>> ietf-routing@2012-02-20.yang:185.7: error(352): invalid = unique-stmt node >>>=20 >>>=20 >>> A unique-stmt for container/list/leaf is not allowed. Only = container and leaf are allowed. >>> RFC 6020 may not be clear on this. Martin should fix it ;-) >>=20 >> I did check the spec before writing that statement, and it doesn't = seem to exclude this case. >> The use case is clear: partition the list of logical interfaces into = sublists and make sure the sublists are disjoint. >>=20 >>>=20 >>> It can work if there is only 1 node in the 'uniqueness tuple and = only 1 list in the path. >>> But except for that special case, list cannot deterministically = produce a set of instances >>> that belong to the same tuple, for comparison to another tuple. >>=20 >> I think it is a matter of definition, and IMO a reasonable definition = is in RFC 6110, sec. 12.16. Of course, I could change the 'unique' = statement into 'must' along these lines but that would be much less = readable. >>=20 >>>=20 >>> If I comment out the unique-stmt, then I get these warnings from = ipv4 and ipv6 modules: >>>=20 >>> Warning: sibling object 'address' already defined in module = 'ietf-ipv4-unicast-routing' at line 85 >>> ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate = sibling node name from external augment >>>=20 >>> Warning: sibling object 'outgoing-interface' already defined in = module 'ietf-routing' at line 132 >>> ietf-routing.yang:132.5: warning(425): duplicate sibling node = name from external augment >>>=20 >>> Warning: sibling object 'dest-prefix' already defined in module = 'ietf-ipv4-unicast-routing' at line 63 >>> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate = sibling node name from external augment >>>=20 >>> Warning: sibling object 'next-hop' already defined in module = 'ietf-ipv4-unicast-routing' at line 68 >>> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate = sibling node name from external augment >>>=20 >>> Warning: sibling object 'outgoing-interface' already defined in = module 'ietf-routing' at line 132 >>> ietf-routing.yang:132.5: warning(425): duplicate sibling node = name from external augment >>>=20 >>> Warning: sibling object 'dest-prefix' already defined in module = 'ietf-ipv4-unicast-routing' at line 63 >>> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate = sibling node name from external augment >>>=20 >>> Warning: sibling object 'next-hop' already defined in module = 'ietf-ipv4-unicast-routing' at line 68 >>> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate = sibling node name from external augment >>>=20 >>> These warnings are because each module does an external augment on >>> the same target, using the same 'route-content' grouping. So all = siblings >>> have duplicate local-names in different namespaces. >>=20 >> I don't see it as a problem. We have next-hop for both IPv4 and for = IPv6, named v4ur:next-hop and v6ur:next-hop. Moreover, the augments are = conditional so that these two can never become siblings - in fact, they = cannot be in the same routing table. >>=20 >>>=20 >>> I really think it sets a bad precedent to intentionally cause = local-name >>> collisions -- to be as XML namespace dependent as possible. >>=20 >> For me namespaces is one of the few reasons for using XML rather = than, e.g., JSON. >>=20 >>> The user-friendly thing to do would be to always add your own = sub-container. >>=20 >> With subcontainers you cannot use leafrefs effectively. That's why we = have a flat list of interfaces. >>=20 >>> This is how CLI keeps things straight. E.g.: >>> (note container insertion before 'uses route-content') >>>=20 >>=20 >> Each 'routing-table' already has 'address-family' and 'safi' as its = children, so it makes little sense to carry the redundant address family = information in each route: >>=20 >> >> ipV6 >> nlri-unicast >> >> >> >> ... >> >> >> ... >> >> ... >> >>=20 >> With 250K routes this can already make a difference. >>=20 >> Lada >>=20 >>>=20 >>> augment = "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >>> + "rt:routes/rt:route" { >>> when "../../rt:address-family=3D'ipV4' and " >>> + "../../rt:safi=3D'nlri-unicast'" { >>> description >>> "This augment is valid only for IPv4 unicast."; >>> } >>> description >>> "This augment defines the content of IPv4 unicast routes."; >>>=20 >>> container ipv4-unicast { >>> uses route-content; >>> } >>> } >>>=20 >>> augment = "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >>> + "rt:routes/rt:route" { >>> when "../../rt:address-family=3D'ipV6' and " >>> + "../../rt:safi=3D'nlri-unicast'" { >>> description >>> "This augment is valid only for IPv6 unicast."; >>> } >>> description >>> "This augment defines the content of IPv6 unicast routes."; >>> container ipv6-unicast { >>> uses route-content; >>> } >>> } >>> } >>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Thu Mar 1 01:21:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9514F21F85F8 for ; Thu, 1 Mar 2012 01:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuthPmE0VVR6 for ; Thu, 1 Mar 2012 01:21:41 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id ADF7821F8644 for ; Thu, 1 Mar 2012 01:21:39 -0800 (PST) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q219LZMf008820 for ; Thu, 1 Mar 2012 04:21:35 -0500 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48489] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5A/D7-22291-F9F3F4F4; Thu, 01 Mar 2012 04:21:35 -0500 Message-ID: <4F4F3FA9.8010406@netconfcentral.org> Date: Thu, 01 Mar 2012 01:21:45 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> In-Reply-To: <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 09:21:46 -0000 On 03/01/2012 12:47 AM, Ladislav Lhotka wrote: > > On Mar 1, 2012, at 9:36 AM, Andy Bierman wrote: > >> On 02/29/2012 11:59 PM, Ladislav Lhotka wrote: >>> On Wed, 29 Feb 2012 13:15:05 -0800, Andy Bierman wrote: >>>> Hi, >>>> >> >> >> I will let implementors vote with their feet. >> If anyone implements this data model, then that shows that it >> is usable just fine and my concerns are unfounded. > > I am now working on such an implementation. :-) > >> >> I don't agree that unique-stmt in YANG allows list or leaf-list. >> I think RFC 6020 is vague on the details. It certainly does not work >> if there is more than 1 node in the tuple. The text does not call out > > The Schematron rule mapped from a 'unique' statement does work even for multiple nodes in the tuple and IMO there is no ambiguity. > container top { unique "a/b c/d"; list a { key random-string; leaf random-string { type string; } leaf b { type string; } } list c { key random-int; leaf random-int { type int32; } leaf d { type string; } } How are instances of 'b' matched with instances of 'd' to form a tuple? > Lada > Andy > >> the special case where the tuple has only 1 schema-node in it. >> >> >> Andy >> >>>> I was trying to update the modules on netconfcentral.org, and yangdump >>>> is complaining about ietf-routing.yang. 1 fatal error and some warnings. >>>> >>>> unique "interfaces/interface/name"; >>>> >>>> Error: list node (interface) within unique stmt 'interfaces/interface/name' for node 'interfaces/interface/name' >>>> ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node >>>> >>>> >>>> A unique-stmt for container/list/leaf is not allowed. Only container and leaf are allowed. >>>> RFC 6020 may not be clear on this. Martin should fix it ;-) >>> >>> I did check the spec before writing that statement, and it doesn't seem to exclude this case. >>> The use case is clear: partition the list of logical interfaces into sublists and make sure the sublists are disjoint. >>> >>>> >>>> It can work if there is only 1 node in the 'uniqueness tuple and only 1 list in the path. >>>> But except for that special case, list cannot deterministically produce a set of instances >>>> that belong to the same tuple, for comparison to another tuple. >>> >>> I think it is a matter of definition, and IMO a reasonable definition is in RFC 6110, sec. 12.16. Of course, I could change the 'unique' statement into 'must' along these lines but that would be much less readable. >>> >>>> >>>> If I comment out the unique-stmt, then I get these warnings from ipv4 and ipv6 modules: >>>> >>>> Warning: sibling object 'address' already defined in module 'ietf-ipv4-unicast-routing' at line 85 >>>> ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate sibling node name from external augment >>>> >>>> Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 >>>> ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment >>>> >>>> Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 >>>> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment >>>> >>>> Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 >>>> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment >>>> >>>> Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 >>>> ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment >>>> >>>> Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 >>>> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment >>>> >>>> Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 >>>> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment >>>> >>>> These warnings are because each module does an external augment on >>>> the same target, using the same 'route-content' grouping. So all siblings >>>> have duplicate local-names in different namespaces. >>> >>> I don't see it as a problem. We have next-hop for both IPv4 and for IPv6, named v4ur:next-hop and v6ur:next-hop. Moreover, the augments are conditional so that these two can never become siblings - in fact, they cannot be in the same routing table. >>> >>>> >>>> I really think it sets a bad precedent to intentionally cause local-name >>>> collisions -- to be as XML namespace dependent as possible. >>> >>> For me namespaces is one of the few reasons for using XML rather than, e.g., JSON. >>> >>>> The user-friendly thing to do would be to always add your own sub-container. >>> >>> With subcontainers you cannot use leafrefs effectively. That's why we have a flat list of interfaces. >>> >>>> This is how CLI keeps things straight. E.g.: >>>> (note container insertion before 'uses route-content') >>>> >>> >>> Each 'routing-table' already has 'address-family' and 'safi' as its children, so it makes little sense to carry the redundant address family information in each route: >>> >>> >>> ipV6 >>> nlri-unicast >>> >>> >>> >>> ... >>> >>> >>> ... >>> >>> ... >>> >>> >>> With 250K routes this can already make a difference. >>> >>> Lada >>> >>>> >>>> augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >>>> + "rt:routes/rt:route" { >>>> when "../../rt:address-family='ipV4' and " >>>> + "../../rt:safi='nlri-unicast'" { >>>> description >>>> "This augment is valid only for IPv4 unicast."; >>>> } >>>> description >>>> "This augment defines the content of IPv4 unicast routes."; >>>> >>>> container ipv4-unicast { >>>> uses route-content; >>>> } >>>> } >>>> >>>> augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >>>> + "rt:routes/rt:route" { >>>> when "../../rt:address-family='ipV6' and " >>>> + "../../rt:safi='nlri-unicast'" { >>>> description >>>> "This augment is valid only for IPv6 unicast."; >>>> } >>>> description >>>> "This augment defines the content of IPv6 unicast routes."; >>>> container ipv6-unicast { >>>> uses route-content; >>>> } >>>> } >>>> } >>>> >>>> >>>> >>>> Andy >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > > From lhotka@nic.cz Thu Mar 1 02:22:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A3221F8707 for ; Thu, 1 Mar 2012 02:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMmJ6bhuanUM for ; Thu, 1 Mar 2012 02:22:11 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DBB3421F8704 for ; Thu, 1 Mar 2012 02:22:10 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 19DD02A2FA9; Thu, 1 Mar 2012 11:22:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330597329; bh=dDRo+YNHLHEhPtuiU2Rb4C5JejDVt4LBbFPEyqurJUE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L4suAqxvITDIFgKfWck8Mwz5/ZqMkHqIGKjMtxU8mvFHYzv7qlL3in4GB4VP2FwWC KakzuDMLp+p0XWKkBekT9/Ig+4jCC1pnnYn0+t6hkR0f5dw82+wWqRfBoDkre3iK0G eYECKcgsXJxTL+cp6bngiM8hDDI0idontaYGqRiY= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F4F3FA9.8010406@netconfcentral.org> Date: Thu, 1 Mar 2012 11:22:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 10:22:12 -0000 On Mar 1, 2012, at 10:21 AM, Andy Bierman wrote: > container top { > unique "a/b c/d"; > list a { > key random-string; > leaf random-string { type string; } > leaf b { type string; } > } > list c { > key random-int; > leaf random-int { type int32; } > leaf d { type string; } > } >=20 > How are instances of 'b' matched with instances of 'd' to form a = tuple? 'unique' is not allowed under 'container', so it must be something like module unique { namespace "http://unique"; prefix uq; list top { key "clef"; unique "a/b c/d"; leaf clef { type uint8; } list a { key "random-string"; leaf random-string { type string; } leaf b { type string; } } list c { key "random-int"; leaf random-int { type uint32; } leaf d { type string; } } } } OK, let's see - yang2dsdl maps the 'unique' statement to the following = Schematron rule: Violated uniqueness for "uq:a/uq:b uq:c/uq:d" which means: IF two different entries E1 and E2 of the "top" list = contain both a/b and c/d (each possibly in multiple instances), THEN = there must not be a/b anywhere in E1 with the same value as any a/b in = E2 AND there must not be c/d anywhere in E1 with the same value as any = c/d in E2. In other words, any combination of (a/b c/d) found in E1 must be = different from any combination of (a/b c/d) in E2. IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially the = same thing. Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From Jonathan.Hansford@generaldynamics.uk.com Thu Mar 1 03:37:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA2F21F86C9 for ; Thu, 1 Mar 2012 03:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QUcm0T9wHxG for ; Thu, 1 Mar 2012 03:37:40 -0800 (PST) Received: from mail92.messagelabs.com (mail92.messagelabs.com [194.106.220.51]) by ietfa.amsl.com (Postfix) with SMTP id 978F521F86C1 for ; Thu, 1 Mar 2012 03:37:39 -0800 (PST) X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-7.tower-92.messagelabs.com!1330601857!64249468!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23574 invoked from network); 1 Mar 2012 11:37:37 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-7.tower-92.messagelabs.com with SMTP; 1 Mar 2012 11:37:37 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 01 Mar 2012 11:37:42 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 11:37:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 11:37:37 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E650546206791B82@GDUKADH850.uk1.r-org.net> In-Reply-To: <4F4E9559.2000008@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 Thread-Index: Acz3n7NZdMXT4ahHT+WlCqG4QHns7A== References: <4F4E9559.2000008@netconfcentral.org> From: To: , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 01 Mar 2012 11:37:37.0645 (UTC) FILETIME=[B3DE41D0:01CCF79F] Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:37:41 -0000 I'm in the process of evaluating two commercial YANG editors/validators: SegueSoft (formerly ChampNMS) MasterYANG MG-SOFT Visual YANG Designer I thought I'd try validating ietf-routing.yang to see whether either of those tools flagged up a similar error. Unfortunately the former didn't detect that one of the imported files I had created from the RFC still had some page headers/footers embedded and claimed no errors were found (I've notified SegueSoft of the issue).=20 That just left YANG Designer. On correcting the file in error ietfrouting.yang validated with no errors or warnings. Either their code isn't as tight as yangdump or they come down on the other side of the ambiguity. Jonathan Hansford > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.org] > Sent: 29 February 2012 21:15 > To: NETMOD Working Group > Subject: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 >=20 > Hi, >=20 > I was trying to update the modules on netconfcentral.org, and yangdump > is complaining about ietf-routing.yang. 1 fatal error and some warnings. >=20 > unique "interfaces/interface/name"; >=20 > Error: list node (interface) within unique stmt > 'interfaces/interface/name' for node 'interfaces/interface/name' > ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt > node >=20 >=20 > A unique-stmt for container/list/leaf is not allowed. Only container and > leaf are allowed. > RFC 6020 may not be clear on this. Martin should fix it ;-) >=20 > It can work if there is only 1 node in the 'uniqueness tuple and only 1 > list in the path. > But except for that special case, list cannot deterministically produce a > set of instances > that belong to the same tuple, for comparison to another tuple. >=20 > If I comment out the unique-stmt, then I get these warnings from ipv4 and > ipv6 modules: >=20 > Warning: sibling object 'address' already defined in module 'ietf- > ipv4-unicast-routing' at line 85 > ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate sibling > node name from external augment >=20 > Warning: sibling object 'outgoing-interface' already defined in > module 'ietf-routing' at line 132 > ietf-routing.yang:132.5: warning(425): duplicate sibling node name > from external augment >=20 > Warning: sibling object 'dest-prefix' already defined in module > 'ietf-ipv4-unicast-routing' at line 63 > ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling > node name from external augment >=20 > Warning: sibling object 'next-hop' already defined in module 'ietf- > ipv4-unicast-routing' at line 68 > ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling > node name from external augment >=20 > Warning: sibling object 'outgoing-interface' already defined in > module 'ietf-routing' at line 132 > ietf-routing.yang:132.5: warning(425): duplicate sibling node name > from external augment >=20 > Warning: sibling object 'dest-prefix' already defined in module > 'ietf-ipv4-unicast-routing' at line 63 > ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling > node name from external augment >=20 > Warning: sibling object 'next-hop' already defined in module 'ietf- > ipv4-unicast-routing' at line 68 > ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling > node name from external augment >=20 > These warnings are because each module does an external augment on > the same target, using the same 'route-content' grouping. So all siblings > have duplicate local-names in different namespaces. >=20 > I really think it sets a bad precedent to intentionally cause local-name > collisions -- to be as XML namespace dependent as possible. > The user-friendly thing to do would be to always add your own sub- > container. > This is how CLI keeps things straight. E.g.: > (note container insertion before 'uses route-content') >=20 >=20 > augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" > + "rt:routes/rt:route" { > when "../../rt:address-family=3D'ipV4' and " > + "../../rt:safi=3D'nlri-unicast'" { > description > "This augment is valid only for IPv4 unicast."; > } > description > "This augment defines the content of IPv4 unicast routes."; >=20 > container ipv4-unicast { > uses route-content; > } > } >=20 > augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" > + "rt:routes/rt:route" { > when "../../rt:address-family=3D'ipV6' and " > + "../../rt:safi=3D'nlri-unicast'" { > description > "This augment is valid only for IPv6 unicast."; > } > description > "This augment defines the content of IPv6 unicast routes."; > container ipv6-unicast { > uses route-content; > } > } > } >=20 >=20 >=20 > Andy >=20 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From lhotka@nic.cz Thu Mar 1 04:00:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4964521F86BD for ; Thu, 1 Mar 2012 04:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwabcrG2nTpk for ; Thu, 1 Mar 2012 04:00:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC2E21F8629 for ; Thu, 1 Mar 2012 04:00:44 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id ED8792A2FB1; Thu, 1 Mar 2012 13:00:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330603243; bh=+RWYLQT7wQ820Vx3bwPB8NefbqF9SGvmWVIK7uMJwnQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=H0dxFC4gqmbDyZZ5Ig7e1kp/TGf/WSspQ71LQNumkWYMQUWMI118n6abpiIXn0FkL 5MQS3XtPI798+C5hDMtabYg2WxMKzehpzuudXKYmuTJxq4Q7vCqZIsMLoBVksbNWLW bfQZs5t7PjWO93A3gG1OJvgLTug8nd6CaqAtrUn4= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206791B82@GDUKADH850.uk1.r-org.net> Date: Thu, 1 Mar 2012 13:00:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4395FB75-01CE-4480-A2C9-FBF76103B628@nic.cz> References: <4F4E9559.2000008@netconfcentral.org> <83C941F7F59F3F42AC017AD1E650546206791B82@GDUKADH850.uk1.r-org.net> To: X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 12:00:45 -0000 On Mar 1, 2012, at 12:37 PM, = wrote: > I'm in the process of evaluating two commercial YANG = editors/validators: > SegueSoft (formerly ChampNMS) MasterYANG > MG-SOFT Visual YANG Designer >=20 > I thought I'd try validating ietf-routing.yang to see whether either = of > those tools flagged up a similar error. Unfortunately the former = didn't > detect that one of the imported files I had created from the RFC still > had some page headers/footers embedded and claimed no errors were = found > (I've notified SegueSoft of the issue).=20 >=20 > That just left YANG Designer. On correcting the file in error > ietfrouting.yang validated with no errors or warnings. So does pyang. >=20 > Either their code isn't as tight as yangdump or they come down on the > other side of the ambiguity. In this case, yangdump is hypercorrect and flags errors that don't = exist. Perhaps RFC 6020 needs a minor clarification but IMO nothing like the = CLRs that Andy suggests. Lada >=20 > Jonathan Hansford >=20 >> -----Original Message----- >> From: Andy Bierman [mailto:andy@netconfcentral.org] >> Sent: 29 February 2012 21:15 >> To: NETMOD Working Group >> Subject: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 >>=20 >> Hi, >>=20 >> I was trying to update the modules on netconfcentral.org, and = yangdump >> is complaining about ietf-routing.yang. 1 fatal error and some > warnings. >>=20 >> unique "interfaces/interface/name"; >>=20 >> Error: list node (interface) within unique stmt >> 'interfaces/interface/name' for node 'interfaces/interface/name' >> ietf-routing@2012-02-20.yang:185.7: error(352): invalid > unique-stmt >> node >>=20 >>=20 >> A unique-stmt for container/list/leaf is not allowed. Only container > and >> leaf are allowed. >> RFC 6020 may not be clear on this. Martin should fix it ;-) >>=20 >> It can work if there is only 1 node in the 'uniqueness tuple and only > 1 >> list in the path. >> But except for that special case, list cannot deterministically > produce a >> set of instances >> that belong to the same tuple, for comparison to another tuple. >>=20 >> If I comment out the unique-stmt, then I get these warnings from ipv4 > and >> ipv6 modules: >>=20 >> Warning: sibling object 'address' already defined in module > 'ietf- >> ipv4-unicast-routing' at line 85 >> ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate > sibling >> node name from external augment >>=20 >> Warning: sibling object 'outgoing-interface' already defined in >> module 'ietf-routing' at line 132 >> ietf-routing.yang:132.5: warning(425): duplicate sibling node > name >> from external augment >>=20 >> Warning: sibling object 'dest-prefix' already defined in module >> 'ietf-ipv4-unicast-routing' at line 63 >> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate > sibling >> node name from external augment >>=20 >> Warning: sibling object 'next-hop' already defined in module > 'ietf- >> ipv4-unicast-routing' at line 68 >> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate > sibling >> node name from external augment >>=20 >> Warning: sibling object 'outgoing-interface' already defined in >> module 'ietf-routing' at line 132 >> ietf-routing.yang:132.5: warning(425): duplicate sibling node > name >> from external augment >>=20 >> Warning: sibling object 'dest-prefix' already defined in module >> 'ietf-ipv4-unicast-routing' at line 63 >> ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate > sibling >> node name from external augment >>=20 >> Warning: sibling object 'next-hop' already defined in module > 'ietf- >> ipv4-unicast-routing' at line 68 >> ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate > sibling >> node name from external augment >>=20 >> These warnings are because each module does an external augment on >> the same target, using the same 'route-content' grouping. So all > siblings >> have duplicate local-names in different namespaces. >>=20 >> I really think it sets a bad precedent to intentionally cause > local-name >> collisions -- to be as XML namespace dependent as possible. >> The user-friendly thing to do would be to always add your own sub- >> container. >> This is how CLI keeps things straight. E.g.: >> (note container insertion before 'uses route-content') >>=20 >>=20 >> augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >> + "rt:routes/rt:route" { >> when "../../rt:address-family=3D'ipV4' and " >> + "../../rt:safi=3D'nlri-unicast'" { >> description >> "This augment is valid only for IPv4 unicast."; >> } >> description >> "This augment defines the content of IPv4 unicast routes."; >>=20 >> container ipv4-unicast { >> uses route-content; >> } >> } >>=20 >> augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" >> + "rt:routes/rt:route" { >> when "../../rt:address-family=3D'ipV6' and " >> + "../../rt:safi=3D'nlri-unicast'" { >> description >> "This augment is valid only for IPv6 unicast."; >> } >> description >> "This augment defines the content of IPv6 unicast routes."; >> container ipv6-unicast { >> uses route-content; >> } >> } >> } >>=20 >>=20 >>=20 >> Andy >>=20 >=20 >=20 >=20 > This email and any files attached are intended for the addressee and = may contain information of a confidential nature. If you are not the = intended recipient, be aware that this email was sent to you in error = and you should not disclose, distribute, print, copy or make other use = of this email or its attachments. Such actions, in fact, may be = unlawful. In compliance with the various Regulations and Acts, General = Dynamics United Kingdom Limited reserves the right to monitor (and = examine for viruses) all emails and email attachments, both inbound and = outbound. Email communications and their attachments may not be secure = or error- or virus-free and the company does not accept liability or = responsibility for such matters or the consequences thereof. General = Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, = London EC1A 2DY. Registered in England and Wales No: 1911653.=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Thu Mar 1 06:23:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEBC21E82DB for ; Thu, 1 Mar 2012 06:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mdq96WobMZqd for ; Thu, 1 Mar 2012 06:23:19 -0800 (PST) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id C994B21E8276 for ; Thu, 1 Mar 2012 06:23:18 -0800 (PST) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q21ENHlV007181 for ; Thu, 1 Mar 2012 09:23:17 -0500 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48787] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 9A/23-22291-4568F4F4; Thu, 01 Mar 2012 09:23:17 -0500 Message-ID: <4F4F865F.7070305@netconfcentral.org> Date: Thu, 01 Mar 2012 06:23:27 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> In-Reply-To: <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:23:19 -0000 On 03/01/2012 02:22 AM, Ladislav Lhotka wrote: > On Mar 1, 2012, at 10:21 AM, Andy Bierman wrote: > >> container top { >> unique "a/b c/d"; >> list a { >> key random-string; >> leaf random-string { type string; } >> leaf b { type string; } >> } >> list c { >> key random-int; >> leaf random-int { type int32; } >> leaf d { type string; } >> } >> >> How are instances of 'b' matched with instances of 'd' to form a tuple? > > 'unique' is not allowed under 'container', so it must be something like > > module unique { > namespace "http://unique"; > prefix uq; > > list top { > key "clef"; > unique "a/b c/d"; > leaf clef { > type uint8; > } > list a { > key "random-string"; > leaf random-string { > type string; > } > leaf b { > type string; > } > } > list c { > key "random-int"; > leaf random-int { > type uint32; > } > leaf d { > type string; > } > } > } > } > > OK, let's see - yang2dsdl maps the 'unique' statement to the following Schematron rule: > > > > Violated uniqueness for "uq:a/uq:b uq:c/uq:d" > > > which means: IF two different entries E1 and E2 of the "top" list contain both a/b and c/d (each possibly in multiple instances), THEN there must not be a/b anywhere in E1 with the same value as any a/b in E2 AND there must not be c/d anywhere in E1 with the same value as any c/d in E2. > Tuples contain only leafs, so the unique-stmt compares a set of leaf values from one list entry against all the other list entries. You are expanding the instance tuple into a matrix, so each leaf in the tuple is not a single value but a complex matrix of keys and instances Vi = { top[i]/a[*]/b, top[i]/c[*]/d } E.g. V(22) = { {top[22]/a['fred']/b, top[22]/a['wilma']/b} , { top[22]/c[6]/d, top[22]/c[7]/d, top[22]/c[16]/d } } So instead of comparing a set of 2 leaf values to another set of 2 leaf values (V(1) to V(2), V(1) to V(3), etc.) you claim the server is supposed compare a set of 2 arrays of leaf values to another set of 2 arrays of leaf values. Do the keys need to exactly match (across 'b' for example)? What happens if they don't? What constitutes an incomplete tuple? > In other words, any combination of (a/b c/d) found in E1 must be different from any combination of (a/b c/d) in E2. > > IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially the same thing. > > Lada > Andy From andy@netconfcentral.org Thu Mar 1 06:45:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DE321E8309 for ; Thu, 1 Mar 2012 06:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxMcKfpJNx0j for ; Thu, 1 Mar 2012 06:45:36 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5F22621E82F0 for ; Thu, 1 Mar 2012 06:45:36 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q21EjYqg008299 for ; Thu, 1 Mar 2012 09:45:34 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48805] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 26/1F-32269-E8B8F4F4; Thu, 01 Mar 2012 09:45:34 -0500 Message-ID: <4F4F8B98.5060200@netconfcentral.org> Date: Thu, 01 Mar 2012 06:45:44 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> In-Reply-To: <4F4F865F.7070305@netconfcentral.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:45:37 -0000 ... > > Tuples contain only leafs, so the unique-stmt compares a set of leaf values > from one list entry against all the other list entries. > > You are expanding the instance tuple into a matrix, so each leaf in the tuple > is not a single value but a complex matrix of keys and instances > > Vi = { top[i]/a[*]/b, top[i]/c[*]/d } > > E.g. > > V(22) = { {top[22]/a['fred']/b, top[22]/a['wilma']/b} , { top[22]/c[6]/d, top[22]/c[7]/d, top[22]/c[16]/d } } > > So instead of comparing a set of 2 leaf values to another set of 2 leaf values (V(1) to V(2), V(1) to V(3), etc.) > you claim the server is supposed compare a set of 2 arrays of leaf values to another > set of 2 arrays of leaf values. Do the keys need to exactly match (across 'b' for example)? > What happens if they don't? What constitutes an incomplete tuple? > > >> In other words, any combination of (a/b c/d) found in E1 must be different from any combination of (a/b c/d) in E2. >> >> IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially the same thing. >> list router { key "name"; unique "interfaces/interface/name"; .... So what this unique-stmt says it that for each router[name='foo'], compare the array of interface names. But 'name' is also a key: Vi = { router[name=i]/interfaces/interface[name=*]/name } So 1 entry Vi is a set of logical interface names assigned to router 'i', maybe: V1 = { 'eth0', 'eth1' } V2 = { 'eth1', 'eth2', 'eth3'} There is no unique error for 'eth1' because the entire set of interface names per router must match the exact instances of another entry or the 'tuple' is not considered a match. Is this what you want? I can't tell from the descriptions. If you intend that a logical interface can appear in zero or 1 routers, that is not what this unique-stmt does. >> Lada >> > > > Andy Andy From lhotka@nic.cz Thu Mar 1 07:03:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95021E8169 for ; Thu, 1 Mar 2012 07:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxjNRUw+ZCtQ for ; Thu, 1 Mar 2012 07:03:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DD0DF21E8163 for ; Thu, 1 Mar 2012 07:03:03 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 9BDD52A276D; Thu, 1 Mar 2012 16:03:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330614182; bh=bOReQj42YIHmC3ovt8d9XQc9M9nKcqihBRIM+Kpx4dM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fmroGSvocOyByfM4MoBgg8NAHEOU+6SFAOC24WKuZgbtoP9TAHDMcTtjKiqy5OUWP TcclX6Uz8uK+X6VbQ0vulSHlH36makHrR/0aZg5ySIN8xtaqwOmG+zE8lGfCp0vyJo RdIlq9G6aqoBrAWNL++7WVmeiqUy+WJQrbJQmLV0= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F4F865F.7070305@netconfcentral.org> Date: Thu, 1 Mar 2012 16:03:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <313F6634-139B-4EEB-9796-59AE1B5C3797@nic.cz> References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:03:05 -0000 On Mar 1, 2012, at 3:23 PM, Andy Bierman wrote: > On 03/01/2012 02:22 AM, Ladislav Lhotka wrote: >> On Mar 1, 2012, at 10:21 AM, Andy Bierman wrote: >>=20 >>> container top { >>> unique "a/b c/d"; >>> list a { >>> key random-string; >>> leaf random-string { type string; } >>> leaf b { type string; } >>> } >>> list c { >>> key random-int; >>> leaf random-int { type int32; } >>> leaf d { type string; } >>> } >>>=20 >>> How are instances of 'b' matched with instances of 'd' to form a = tuple? >>=20 >> 'unique' is not allowed under 'container', so it must be something = like >>=20 >> module unique { >> namespace "http://unique"; >> prefix uq; >>=20 >> list top { >> key "clef"; >> unique "a/b c/d"; >> leaf clef { >> type uint8; >> } >> list a { >> key "random-string"; >> leaf random-string { >> type string; >> } >> leaf b { >> type string; >> } >> } >> list c { >> key "random-int"; >> leaf random-int { >> type uint32; >> } >> leaf d { >> type string; >> } >> } >> } >> } >>=20 >> OK, let's see - yang2dsdl maps the 'unique' statement to the = following Schematron rule: >>=20 >> >> > and uq:c/uq:d=3Dcurrent()/uq:c/uq:d]"> >> Violated uniqueness for "uq:a/uq:b uq:c/uq:d" >> >>=20 >> which means: IF two different entries E1 and E2 of the "top" list = contain both a/b and c/d (each possibly in multiple instances), THEN = there must not be a/b anywhere in E1 with the same value as any a/b in = E2 AND there must not be c/d anywhere in E1 with the same value as any = c/d in E2. >>=20 >=20 > Tuples contain only leafs, so the unique-stmt compares a set of leaf = values > from one list entry against all the other list entries. >=20 > You are expanding the instance tuple into a matrix, so each leaf in = the tuple > is not a single value but a complex matrix of keys and instances >=20 > Vi =3D { top[i]/a[*]/b, top[i]/c[*]/d } >=20 > E.g. >=20 > V(22) =3D { {top[22]/a['fred']/b, top[22]/a['wilma']/b} , { = top[22]/c[6]/d, top[22]/c[7]/d, top[22]/c[16]/d } } >=20 > So instead of comparing a set of 2 leaf values to another set of 2 = leaf values (V(1) to V(2), V(1) to V(3), etc.) > you claim the server is supposed compare a set of 2 arrays of leaf = values to another Well, instead of 'unique' I can use 'must' with just the Schematron = XPath expression. If the server is able to handle any XPath 1.0 = expression in 'must', it should also be able to cope with this = interpretation of 'unique'.=20 > set of 2 arrays of leaf values. Do the keys need to exactly match = (across 'b' for example)? If we accept XPath rules, then a/b doesn't care about what the key of a = is, so the list keys (of a and c) are not relevant to the validation of = 'unique', which can be done exactly as Schematron does. > What happens if they don't? What constitutes an incomplete tuple? This is answered in 6020: list entries that don't have all of the nodes = from the tuple (including defaults) are not taken into account. Lada >=20 >=20 >> In other words, any combination of (a/b c/d) found in E1 must be = different from any combination of (a/b c/d) in E2. >>=20 >> IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially the = same thing. >>=20 >> Lada >>=20 >=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Mar 1 07:17:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81DD21E81B0 for ; Thu, 1 Mar 2012 07:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmLjmn3Ke4hn for ; Thu, 1 Mar 2012 07:17:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CEB4221E803E for ; Thu, 1 Mar 2012 07:16:59 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 1060F2A03DA; Thu, 1 Mar 2012 16:16:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330615019; bh=EAq1rMoQhbXbRQCJw8GifJ0s+DbQ0hqCqteFy3meSeU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ba2WAAGdaGbCdxLUf1B8FrerElVsOoxx12uivQldc2qpKGXSVnHiRzBhvy3BWXfaC 6G6e9yLnkFCBZS9l2nobYEY1q5sSjH81CEtZ/4O2+JkRcF4W/zJE3o7YZKUA/1zjH7 cwbWMIt6Q4ceZKlc3zdrsPP/wouUi/g/hcTFCXy0= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F4F8B98.5060200@netconfcentral.org> Date: Thu, 1 Mar 2012 16:16:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> <4F4F8B98.5060200@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:17:00 -0000 On Mar 1, 2012, at 3:45 PM, Andy Bierman wrote: > ... >>=20 >> Tuples contain only leafs, so the unique-stmt compares a set of leaf = values >> from one list entry against all the other list entries. >>=20 >> You are expanding the instance tuple into a matrix, so each leaf in = the tuple >> is not a single value but a complex matrix of keys and instances >>=20 >> Vi =3D { top[i]/a[*]/b, top[i]/c[*]/d } >>=20 >> E.g. >>=20 >> V(22) =3D { {top[22]/a['fred']/b, top[22]/a['wilma']/b} , { = top[22]/c[6]/d, top[22]/c[7]/d, top[22]/c[16]/d } } >>=20 >> So instead of comparing a set of 2 leaf values to another set of 2 = leaf values (V(1) to V(2), V(1) to V(3), etc.) >> you claim the server is supposed compare a set of 2 arrays of leaf = values to another >> set of 2 arrays of leaf values. Do the keys need to exactly match = (across 'b' for example)? >> What happens if they don't? What constitutes an incomplete tuple? >>=20 >>=20 >>> In other words, any combination of (a/b c/d) found in E1 must be = different from any combination of (a/b c/d) in E2. >>>=20 >>> IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially = the same thing. >>>=20 >=20 >=20 >=20 > list router { > key "name"; > unique "interfaces/interface/name"; > .... >=20 > So what this unique-stmt says it that for each router[name=3D'foo'], > compare the array of interface names. But 'name' is also a key: >=20 > Vi =3D { router[name=3Di]/interfaces/interface[name=3D*]/name } >=20 >=20 > So 1 entry Vi is a set of logical interface names assigned to router = 'i', maybe: >=20 > V1 =3D { 'eth0', 'eth1' } > V2 =3D { 'eth1', 'eth2', 'eth3'} >=20 > There is no unique error for 'eth1' because the entire set of = interface names per router > must match the exact instances of another entry or the 'tuple' is not > considered a match. Is this what you want? I can't tell from the = descriptions. OK, so I should improve the description. >=20 > If you intend that a logical interface can appear in zero or 1 = routers, that is > not what this unique-stmt does. Yes, that's the idea, and the Schematron rule generated from that = 'unique' statement does the right thing, as far as I can tell: Two = different router entries cannot have the same value of = interfaces/interface/name node.=20 Lada >=20 >>> Lada >>>=20 >>=20 >>=20 >> Andy >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Thu Mar 1 07:49:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1928D21E8203 for ; Thu, 1 Mar 2012 07:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syMz7HvLGJoz for ; Thu, 1 Mar 2012 07:49:11 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 041F621E81FF for ; Thu, 1 Mar 2012 07:49:10 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q21Fn9q6029584 for ; Thu, 1 Mar 2012 10:49:09 -0500 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48872] helo=[192.168.0.9]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 50/61-22803-47A9F4F4; Thu, 01 Mar 2012 10:49:09 -0500 Message-ID: <4F4F9A7F.3090502@netconfcentral.org> Date: Thu, 01 Mar 2012 07:49:19 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> <4F4F8B98.5060200@netconfcentral.org> <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> In-Reply-To: <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:49:12 -0000 On 03/01/2012 07:16 AM, Ladislav Lhotka wrote: > > On Mar 1, 2012, at 3:45 PM, Andy Bierman wrote: > >> ... >>> >>> Tuples contain only leafs, so the unique-stmt compares a set of leaf values >>> from one list entry against all the other list entries. >>> >>> You are expanding the instance tuple into a matrix, so each leaf in the tuple >>> is not a single value but a complex matrix of keys and instances >>> >>> Vi = { top[i]/a[*]/b, top[i]/c[*]/d } >>> >>> E.g. >>> >>> V(22) = { {top[22]/a['fred']/b, top[22]/a['wilma']/b} , { top[22]/c[6]/d, top[22]/c[7]/d, top[22]/c[16]/d } } >>> >>> So instead of comparing a set of 2 leaf values to another set of 2 leaf values (V(1) to V(2), V(1) to V(3), etc.) >>> you claim the server is supposed compare a set of 2 arrays of leaf values to another >>> set of 2 arrays of leaf values. Do the keys need to exactly match (across 'b' for example)? >>> What happens if they don't? What constitutes an incomplete tuple? >>> >>> >>>> In other words, any combination of (a/b c/d) found in E1 must be different from any combination of (a/b c/d) in E2. >>>> >>>> IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially the same thing. >>>> >> >> >> >> list router { >> key "name"; >> unique "interfaces/interface/name"; >> .... >> >> So what this unique-stmt says it that for each router[name='foo'], >> compare the array of interface names. But 'name' is also a key: >> >> Vi = { router[name=i]/interfaces/interface[name=*]/name } >> >> >> So 1 entry Vi is a set of logical interface names assigned to router 'i', maybe: >> >> V1 = { 'eth0', 'eth1' } >> V2 = { 'eth1', 'eth2', 'eth3'} >> >> There is no unique error for 'eth1' because the entire set of interface names per router >> must match the exact instances of another entry or the 'tuple' is not >> considered a match. Is this what you want? I can't tell from the descriptions. > > OK, so I should improve the description. > >> >> If you intend that a logical interface can appear in zero or 1 routers, that is >> not what this unique-stmt does. > > Yes, that's the idea, and the Schematron rule generated from that 'unique' statement does the right thing, as far as I can tell: Two different router entries cannot have the same value of interfaces/interface/name node. > But each interfaces/interface list within the router list can have a different set of instances. There may not be just 1 interfaces/interface/name node? What is the node value if there are 2 instances for router[1] and 3 instances for router[2]. like in my example above? list top { key idx; unique foo/a; leaf idx { type int32; } list foo { key j; leaf j { type int32; ] leaf a { type int32; } } } tuple = { node-set } == { node-set values } Vi = top[idx=i]/foo[j=*]/a V1 = {a[1] = 5} == { 5 } V2 = {a[2] = 10, a[7] = 5} == { 10, 5 } V3 = {a[2] = 5, a[7] = 10, a[9] = 20} == { 5, 10, 20 } V4 = { } == { } (only top entry skipped in test) So is this no unique-error because none of the 'values' of Vi are the same? I.e., no tuples actually match? This seems consistent with the language in RFC 6020, sec 7.8.3. Or is it a unique-error because some values (node-sets) matches the equality test according to XPath rules for comparing node-sets? This is consistent with XPath 1.0 sec 3.4, but it is not intuitive or explicitly stated in the YANG RFC. > Lada Andy From jernej.tuljak@mg-soft.si Thu Mar 1 23:25:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0AB21F89C6 for ; Thu, 1 Mar 2012 23:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrzS73ET8MM6 for ; Thu, 1 Mar 2012 23:25:15 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0E21F87E1 for ; Thu, 1 Mar 2012 23:25:03 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q227P1oO015430; Fri, 2 Mar 2012 08:25:01 +0100 Message-ID: <4F5075CB.1000703@mg-soft.com> Date: Fri, 02 Mar 2012 08:24:59 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> <4F4F8B98.5060200@netconfcentral.org> <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> <4F4F9A7F.3090502@netconfcentral.org> In-Reply-To: <4F4F9A7F.3090502@netconfcentral.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:25:16 -0000 I just tested your example with one of our tools which is based on Ladislav's dsdl pyang plugin. The unique constraint is not violated. But I agree with Ladislav, that this is what should happen in such a case..after all that is what you are saying you want when you construct such a module: I do not want duplicated value entries in my top list when all the referenced leaf instances exist. One could claim, that not all referenced leaf instances exist for vectors which are not of the length of the maximum sized vector in your instance. Different combinations of the same values of course being irrelevant (V1 = {5, 10 , 20}, V2 = {10, 5, 20}: V1 == V2). Here's the instance created by our tool, just to check if we are on the same wavelength: 1 5 2 10 5 3 5 10 20 4 I agree that this needs clarification in the RFC, but yangdump is currently wrong for this case either way. There is no explicit rule in RFC6020 which would make such modules illegal YANG. Jernej Tuljak Dne 1.3.2012 16:49, piše Andy Bierman: > On 03/01/2012 07:16 AM, Ladislav Lhotka wrote: >> >> On Mar 1, 2012, at 3:45 PM, Andy Bierman wrote: >> >>> ... >>>> >>>> Tuples contain only leafs, so the unique-stmt compares a set of >>>> leaf values >>>> from one list entry against all the other list entries. >>>> >>>> You are expanding the instance tuple into a matrix, so each leaf in >>>> the tuple >>>> is not a single value but a complex matrix of keys and instances >>>> >>>> Vi = { top[i]/a[*]/b, top[i]/c[*]/d } >>>> >>>> E.g. >>>> >>>> V(22) = { {top[22]/a['fred']/b, top[22]/a['wilma']/b} , { >>>> top[22]/c[6]/d, top[22]/c[7]/d, top[22]/c[16]/d } } >>>> >>>> So instead of comparing a set of 2 leaf values to another set of 2 >>>> leaf values (V(1) to V(2), V(1) to V(3), etc.) >>>> you claim the server is supposed compare a set of 2 arrays of leaf >>>> values to another >>>> set of 2 arrays of leaf values. Do the keys need to exactly match >>>> (across 'b' for example)? >>>> What happens if they don't? What constitutes an incomplete tuple? >>>> >>>> >>>>> In other words, any combination of (a/b c/d) found in E1 must be >>>>> different from any combination of (a/b c/d) in E2. >>>>> >>>>> IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially >>>>> the same thing. >>>>> >>> >>> >>> >>> list router { >>> key "name"; >>> unique "interfaces/interface/name"; >>> .... >>> >>> So what this unique-stmt says it that for each router[name='foo'], >>> compare the array of interface names. But 'name' is also a key: >>> >>> Vi = { router[name=i]/interfaces/interface[name=*]/name } >>> >>> >>> So 1 entry Vi is a set of logical interface names assigned to router >>> 'i', maybe: >>> >>> V1 = { 'eth0', 'eth1' } >>> V2 = { 'eth1', 'eth2', 'eth3'} >>> >>> There is no unique error for 'eth1' because the entire set of >>> interface names per router >>> must match the exact instances of another entry or the 'tuple' is not >>> considered a match. Is this what you want? I can't tell from the >>> descriptions. >> >> OK, so I should improve the description. >> >>> >>> If you intend that a logical interface can appear in zero or 1 >>> routers, that is >>> not what this unique-stmt does. >> >> Yes, that's the idea, and the Schematron rule generated from that >> 'unique' statement does the right thing, as far as I can tell: Two >> different router entries cannot have the same value of >> interfaces/interface/name node. >> > > But each interfaces/interface list within the router list can have a > different set > of instances. There may not be just 1 interfaces/interface/name node? > What is the node value if there are 2 instances for router[1] and 3 > instances > for router[2]. like in my example above? > > list top { > key idx; > unique foo/a; > leaf idx { type int32; } > list foo { > key j; > leaf j { type int32; ] > leaf a { type int32; } > } > } > > tuple = { node-set } == { node-set values } > > Vi = top[idx=i]/foo[j=*]/a > > V1 = {a[1] = 5} == { 5 } > V2 = {a[2] = 10, a[7] = 5} == { 10, 5 } > V3 = {a[2] = 5, a[7] = 10, a[9] = 20} == { 5, 10, 20 } > V4 = { } == { } (only top entry skipped in test) > > So is this no unique-error because none of the 'values' of Vi are the > same? > I.e., no tuples actually match? This seems consistent with the > language in RFC 6020, sec 7.8.3. > > Or is it a unique-error because some values (node-sets) matches the > equality > test according to XPath rules for comparing node-sets? > This is consistent with XPath 1.0 sec 3.4, but it is not intuitive or > explicitly stated in the YANG RFC. > > > > Lada > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.org Fri Mar 2 01:07:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A3821F8A17 for ; Fri, 2 Mar 2012 01:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6MeXh+9NW0q for ; Fri, 2 Mar 2012 01:07:31 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id F105C21F8A16 for ; Fri, 2 Mar 2012 01:07:15 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2297F8W009720 for ; Fri, 2 Mar 2012 04:07:15 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:52095] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 88/9B-32269-2CD805F4; Fri, 02 Mar 2012 04:07:15 -0500 Message-ID: <4F508DCD.2070101@netconfcentral.org> Date: Fri, 02 Mar 2012 01:07:25 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jernej Tuljak References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> <4F4F8B98.5060200@netconfcentral.org> <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> <4F4F9A7F.3090502@netconfcentral.org> <4F5075CB.1000703@mg-soft.com> In-Reply-To: <4F5075CB.1000703@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 09:07:32 -0000 On 03/01/2012 11:24 PM, Jernej Tuljak wrote: > I just tested your example with one of our tools which is based on Ladislav's dsdl pyang plugin. The unique constraint is not violated. > But I agree with Ladislav, that this is what should happen in such a case..after all that is what you are saying you want when you construct such a module: I do not want duplicated value entries in > my top list when all the referenced leaf instances exist. One could claim, that not all referenced leaf instances exist for vectors which are not of the length of the maximum sized vector in your > instance. Different combinations of the same values of course being irrelevant (V1 = {5, 10 , 20}, V2 = {10, 5, 20}: V1 == V2). > > Here's the instance created by our tool, just to check if we are on the same wavelength: > > xmlns:cu="http://www.mg-soft.com/ns/cartesian-unique"> > > 1 > > 5 > > > > 2 > > 10 > > > 5 > > > > 3 > > 5 > > > 10 > > > 20 > > > > 4 > > > > I agree that this needs clarification in the RFC, but yangdump is currently wrong for this case either way. There is no explicit rule in RFC6020 which would make such modules illegal YANG. > I disagree with you. This is not what the co-editors of the YANG RFC intended with the text in 7.8.3: 7.8.3. The list's unique Statement The "unique" statement is used to put constraints on valid list entries. It takes as an argument a string that contains a space- separated list of schema node identifiers, which MUST be given in the descendant form (see the rule "descendant-schema-nodeid" in Section 12). Each such schema node identifier MUST refer to a leaf. If one of the referenced leafs represents configuration data, then all of the referenced leafs MUST represent configuration data. The "unique" constraint specifies that the combined values of all the leaf instances specified in the argument string, including leafs with default values, MUST be unique within all list entry instances in which all referenced leafs exist. The constraint is enforced according to the rules in Section 8. The unique string syntax is formally defined by the rule "unique-arg" in Section 12. This text does not say anywhere that XPath node-set comparison rules are used to determine "MUST be unique within all list entry instances". The text suggests the opposite to me. The "descendant-schema-nodeid" is a YANG contrsuct, not an XPath construct. The plural "in which all referenced leafs exist" refers to 1 instance each of the nodes in the tuple, not N instances of each node in the tuple. Unique may or may not include order, so { 5, 10 } and { 10, 5 } together may or may not be an error, I don't know. But { 5, 10 } and { 5, 10, 15 } are different values, so they are unique even by your own notion of stretching the rules to change node to node-set in each tuple. > Jernej Tuljak Andy > > Dne 1.3.2012 16:49, piše Andy Bierman: >> On 03/01/2012 07:16 AM, Ladislav Lhotka wrote: >>> >>> On Mar 1, 2012, at 3:45 PM, Andy Bierman wrote: >>> >>>> ... >>>>> >>>>> Tuples contain only leafs, so the unique-stmt compares a set of leaf values >>>>> from one list entry against all the other list entries. >>>>> >>>>> You are expanding the instance tuple into a matrix, so each leaf in the tuple >>>>> is not a single value but a complex matrix of keys and instances >>>>> >>>>> Vi = { top[i]/a[*]/b, top[i]/c[*]/d } >>>>> >>>>> E.g. >>>>> >>>>> V(22) = { {top[22]/a['fred']/b, top[22]/a['wilma']/b} , { top[22]/c[6]/d, top[22]/c[7]/d, top[22]/c[16]/d } } >>>>> >>>>> So instead of comparing a set of 2 leaf values to another set of 2 leaf values (V(1) to V(2), V(1) to V(3), etc.) >>>>> you claim the server is supposed compare a set of 2 arrays of leaf values to another >>>>> set of 2 arrays of leaf values. Do the keys need to exactly match (across 'b' for example)? >>>>> What happens if they don't? What constitutes an incomplete tuple? >>>>> >>>>> >>>>>> In other words, any combination of (a/b c/d) found in E1 must be different from any combination of (a/b c/d) in E2. >>>>>> >>>>>> IMO the third paragraph in RFC 6020, sec. 7.8.3, says essentially the same thing. >>>>>> >>>> >>>> >>>> >>>> list router { >>>> key "name"; >>>> unique "interfaces/interface/name"; >>>> .... >>>> >>>> So what this unique-stmt says it that for each router[name='foo'], >>>> compare the array of interface names. But 'name' is also a key: >>>> >>>> Vi = { router[name=i]/interfaces/interface[name=*]/name } >>>> >>>> >>>> So 1 entry Vi is a set of logical interface names assigned to router 'i', maybe: >>>> >>>> V1 = { 'eth0', 'eth1' } >>>> V2 = { 'eth1', 'eth2', 'eth3'} >>>> >>>> There is no unique error for 'eth1' because the entire set of interface names per router >>>> must match the exact instances of another entry or the 'tuple' is not >>>> considered a match. Is this what you want? I can't tell from the descriptions. >>> >>> OK, so I should improve the description. >>> >>>> >>>> If you intend that a logical interface can appear in zero or 1 routers, that is >>>> not what this unique-stmt does. >>> >>> Yes, that's the idea, and the Schematron rule generated from that 'unique' statement does the right thing, as far as I can tell: Two different router entries cannot have the same value of >>> interfaces/interface/name node. >>> >> >> But each interfaces/interface list within the router list can have a different set >> of instances. There may not be just 1 interfaces/interface/name node? >> What is the node value if there are 2 instances for router[1] and 3 instances >> for router[2]. like in my example above? >> >> list top { >> key idx; >> unique foo/a; >> leaf idx { type int32; } >> list foo { >> key j; >> leaf j { type int32; ] >> leaf a { type int32; } >> } >> } >> >> tuple = { node-set } == { node-set values } >> >> Vi = top[idx=i]/foo[j=*]/a >> >> V1 = {a[1] = 5} == { 5 } >> V2 = {a[2] = 10, a[7] = 5} == { 10, 5 } >> V3 = {a[2] = 5, a[7] = 10, a[9] = 20} == { 5, 10, 20 } >> V4 = { } == { } (only top entry skipped in test) >> >> So is this no unique-error because none of the 'values' of Vi are the same? >> I.e., no tuples actually match? This seems consistent with the >> language in RFC 6020, sec 7.8.3. >> >> Or is it a unique-error because some values (node-sets) matches the equality >> test according to XPath rules for comparing node-sets? >> This is consistent with XPath 1.0 sec 3.4, but it is not intuitive or >> explicitly stated in the YANG RFC. >> >> >> > Lada >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > > From jernej.tuljak@mg-soft.si Fri Mar 2 03:34:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02AB21F8742 for ; Fri, 2 Mar 2012 03:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPelVmTckhtG for ; Fri, 2 Mar 2012 03:34:32 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0821F871B for ; Fri, 2 Mar 2012 03:34:32 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q22BYUCh018758; Fri, 2 Mar 2012 12:34:31 +0100 Message-ID: <4F50B044.9000901@mg-soft.com> Date: Fri, 02 Mar 2012 12:34:28 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> <4F4F8B98.5060200@netconfcentral.org> <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> <4F4F9A7F.3090502@netconfcentral.org> <4F5075CB.1000703@mg-soft.com> <4F508DCD.2070101@netconfcentral.org> In-Reply-To: <4F508DCD.2070101@netconfcentral.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 11:34:33 -0000 Dne 2.3.2012 10:07, piše Andy Bierman: > On 03/01/2012 11:24 PM, Jernej Tuljak wrote: >> I just tested your example with one of our tools which is based on >> Ladislav's dsdl pyang plugin. The unique constraint is not violated. >> But I agree with Ladislav, that this is what should happen in such a >> case..after all that is what you are saying you want when you >> construct such a module: I do not want duplicated value entries in >> my top list when all the referenced leaf instances exist. One could >> claim, that not all referenced leaf instances exist for vectors which >> are not of the length of the maximum sized vector in your >> instance. Different combinations of the same values of course being >> irrelevant (V1 = {5, 10 , 20}, V2 = {10, 5, 20}: V1 == V2). >> >> Here's the instance created by our tool, just to check if we are on >> the same wavelength: >> >> > xmlns:cu="http://www.mg-soft.com/ns/cartesian-unique"> >> >> 1 >> >> 5 >> >> >> >> 2 >> >> 10 >> >> >> 5 >> >> >> >> 3 >> >> 5 >> >> >> 10 >> >> >> 20 >> >> >> >> 4 >> >> >> >> I agree that this needs clarification in the RFC, but yangdump is >> currently wrong for this case either way. There is no explicit rule >> in RFC6020 which would make such modules illegal YANG. >> > > I disagree with you. This is not what the co-editors of the YANG RFC > intended > with the text in 7.8.3: > > > 7.8.3. The list's unique Statement > > The "unique" statement is used to put constraints on valid list > entries. It takes as an argument a string that contains a space- > separated list of schema node identifiers, which MUST be given in the > descendant form (see the rule "descendant-schema-nodeid" in > Section 12). Each such schema node identifier MUST refer to a leaf. > > If one of the referenced leafs represents configuration data, then > all of the referenced leafs MUST represent configuration data. > > The "unique" constraint specifies that the combined values of all the > leaf instances specified in the argument string, including leafs with > default values, MUST be unique within all list entry instances in > which all referenced leafs exist. The constraint is enforced > according to the rules in Section 8. > > The unique string syntax is formally defined by the rule "unique-arg" > in Section 12. > > > This text does not say anywhere that XPath node-set comparison rules are > used to determine "MUST be unique within all list entry instances". > The text suggests the opposite to me. > > The "descendant-schema-nodeid" is a YANG contrsuct, not an XPath > construct. > The plural "in which all referenced leafs exist" refers to 1 instance > each of > the nodes in the tuple, not N instances of each node in the tuple. > > Unique may or may not include order, so { 5, 10 } and { 10, 5 } together > may or may not be an error, I don't know. > > But { 5, 10 } and { 5, 10, 15 } are different values, so they are unique > even by your own notion of stretching the rules to change node to > node-set > in each tuple. > > >> Jernej Tuljak > > > Andy Actually RFC6020 says nothing at all about enforcing the unique constraint - it oddly enough just says "it must be satisfied" (Section 8). But since we are talking about XML instance validation, I believe RFC6110 must be taken into account. And there semantic constraints (which is exactly what a unique is) are enforced through Schematron (therefore relying heavily on XPath assertions). For me it is only natural to assume that some sort of XPath evaluation is going to take place at one point in the future when validating instances with unique constraints. But I am now unsure if Ladislav's implementation is correct. I agree about "in which all referenced leafs exist". A single "referenced leaf" in that text is anything that may be referred to with a decendant-schema-nodeid (and is also a leaf). Therefore it may consequentially refer to an entire array of instance leafs when a list nested within another list is in the path to the referred schema leaf. Any schema node identifier identifies only a schema node, not an instance node. I now do not understand what "combined values of all the leaf instances" means. Perhaps that a union of all of the instance array values must not contain duplicates? Would this satisfy the requirement of the ietf-routing module? I do not know what the true intention was, but that's what it may be interpreted as. Jernej Tuljak From andy@netconfcentral.org Fri Mar 2 07:08:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7167621F865A for ; Fri, 2 Mar 2012 07:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VguPPBJb7-37 for ; Fri, 2 Mar 2012 07:08:43 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id A83BE21F865B for ; Fri, 2 Mar 2012 07:08:43 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q22F8g6U012923 for ; Fri, 2 Mar 2012 10:08:43 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:52377] helo=[192.168.0.9]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 64/31-25783-A72E05F4; Fri, 02 Mar 2012 10:08:42 -0500 Message-ID: <4F50E285.2020103@netconfcentral.org> Date: Fri, 02 Mar 2012 07:08:53 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jernej Tuljak References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> <4F4F8B98.5060200@netconfcentral.org> <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> <4F4F9A7F.3090502@netconfcentral.org> <4F5075CB.1000703@mg-soft.com> <4F508DCD.2070101@netconfcentral.org> <4F50B044.9000901@mg-soft.com> In-Reply-To: <4F50B044.9000901@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:08:45 -0000 On 03/02/2012 03:34 AM, Jernej Tuljak wrote: > Dne 2.3.2012 10:07, piše Andy Bierman: >> On 03/01/2012 11:24 PM, Jernej Tuljak wrote: >>> I just tested your example with one of our tools which is based on Ladislav's dsdl pyang plugin. The unique constraint is not violated. >>> But I agree with Ladislav, that this is what should happen in such a case..after all that is what you are saying you want when you construct such a module: I do not want duplicated value entries in >>> my top list when all the referenced leaf instances exist. One could claim, that not all referenced leaf instances exist for vectors which are not of the length of the maximum sized vector in your >>> instance. Different combinations of the same values of course being irrelevant (V1 = {5, 10 , 20}, V2 = {10, 5, 20}: V1 == V2). >>> >>> Here's the instance created by our tool, just to check if we are on the same wavelength: >>> >>> >> xmlns:cu="http://www.mg-soft.com/ns/cartesian-unique"> >>> >>> 1 >>> >>> 5 >>> >>> >>> >>> 2 >>> >>> 10 >>> >>> >>> 5 >>> >>> >>> >>> 3 >>> >>> 5 >>> >>> >>> 10 >>> >>> >>> 20 >>> >>> >>> >>> 4 >>> >>> >>> >>> I agree that this needs clarification in the RFC, but yangdump is currently wrong for this case either way. There is no explicit rule in RFC6020 which would make such modules illegal YANG. >>> >> >> I disagree with you. This is not what the co-editors of the YANG RFC intended >> with the text in 7.8.3: >> >> >> 7.8.3. The list's unique Statement >> >> The "unique" statement is used to put constraints on valid list >> entries. It takes as an argument a string that contains a space- >> separated list of schema node identifiers, which MUST be given in the >> descendant form (see the rule "descendant-schema-nodeid" in >> Section 12). Each such schema node identifier MUST refer to a leaf. >> >> If one of the referenced leafs represents configuration data, then >> all of the referenced leafs MUST represent configuration data. >> >> The "unique" constraint specifies that the combined values of all the >> leaf instances specified in the argument string, including leafs with >> default values, MUST be unique within all list entry instances in >> which all referenced leafs exist. The constraint is enforced >> according to the rules in Section 8. >> >> The unique string syntax is formally defined by the rule "unique-arg" >> in Section 12. >> >> >> This text does not say anywhere that XPath node-set comparison rules are >> used to determine "MUST be unique within all list entry instances". >> The text suggests the opposite to me. >> >> The "descendant-schema-nodeid" is a YANG contrsuct, not an XPath construct. >> The plural "in which all referenced leafs exist" refers to 1 instance each of >> the nodes in the tuple, not N instances of each node in the tuple. >> >> Unique may or may not include order, so { 5, 10 } and { 10, 5 } together >> may or may not be an error, I don't know. >> >> But { 5, 10 } and { 5, 10, 15 } are different values, so they are unique >> even by your own notion of stretching the rules to change node to node-set >> in each tuple. >> >> >>> Jernej Tuljak >> >> >> Andy > > Actually RFC6020 says nothing at all about enforcing the unique constraint - it oddly enough just says "it must be satisfied" (Section 8). But since we are talking about XML instance validation, I > believe RFC6110 must be taken into account. And there semantic constraints (which is exactly what a unique is) are enforced through Schematron (therefore relying heavily on XPath assertions). For me > it is only natural to assume that some sort of XPath evaluation is going to take place at one point in the future when validating instances with unique constraints. But I am now unsure if Ladislav's > implementation is correct. > There is no reference to RFC 6110 at all in RFC 6020, so it is hard to see how that document has any impact on this one at all. It doesn't. > I agree about "in which all referenced leafs exist". A single "referenced leaf" in that text is anything that may be referred to with a decendant-schema-nodeid (and is also a leaf). Therefore it may > consequentially refer to an entire array of instance leafs when a list nested within another list is in the path to the referred schema leaf. Any schema node identifier identifies only a schema node, > not an instance node. I now do not understand what "combined values of all the leaf instances" means. Perhaps that a union of all of the instance array values must not contain duplicates? Would this > satisfy the requirement of the ietf-routing module? > > I do not know what the true intention was, but that's what it may be interpreted as. > When a standard can be interpreted multiple ways, and the WG then decides that the text does not clearly support any 1 interpretation, then the standard is deemed to be silent on the issue, but it will probably get resolved in a future version. There were several of these in RFC 4741 that are now clarified in RFC 6241. I know the WG never discussed this issue to the detail it is now. There was never once any discussion or consensus that each unique tuple to compare included multiple instances of a node. Since the term 'unique' is not called out to mean "XPath equality test for node-sets", then it does not mean that. The English dictionary meaning of 'unique' is the intention of the WG. > Jernej Tuljak > > Andy From andy@netconfcentral.org Fri Mar 2 08:54:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32C521F854B for ; Fri, 2 Mar 2012 08:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyZQYpgPTxwp for ; Fri, 2 Mar 2012 08:54:35 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0F621F85BD for ; Fri, 2 Mar 2012 08:54:33 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q22GsWce019086 for ; Fri, 2 Mar 2012 11:54:32 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:53304] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 4E/45-29124-84BF05F4; Fri, 02 Mar 2012 11:54:32 -0500 Message-ID: <4F50FB53.4050002@netconfcentral.org> Date: Fri, 02 Mar 2012 08:54:43 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F4E9559.2000008@netconfcentral.org> <4F4F351A.703@netconfcentral.org> <75C5FCC2-7AF2-41D7-9E2D-56DF07338531@nic.cz> <4F4F3FA9.8010406@netconfcentral.org> <7BF1EAA6-EE11-46D9-963E-E33BAD84ABA4@nic.cz> <4F4F865F.7070305@netconfcentral.org> <4F4F8B98.5060200@netconfcentral.org> <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> In-Reply-To: <9BBFC299-548F-412E-948F-1B59C367816C@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:54:35 -0000 Hi, .... >> If you intend that a logical interface can appear in zero or 1 routers, that is >> not what this unique-stmt does. > > Yes, that's the idea, and the Schematron rule generated from that 'unique' statement does the right thing, as far as I can tell: Two different router entries cannot have the same value of interfaces/interface/name node. > I don't think the normative text actually supports this "XPath node-set equality test" interpretation at all. If node-sets are allowed instead of nodes (not clear) then the "combined values of all the leaf instances..." MUST be unique. That is not the same at all as "at least 1 child node from each node-set must have the same string() translation". So unique-stmt clearly does not provide this literal XPath interpretation you want. But must-stmt does, and it is intended to enforce referential integrity across nodes. So use must-stmt instead. > Lada Andy From ietfc@btconnect.com Sat Mar 3 08:19:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6E321F863B for ; Sat, 3 Mar 2012 08:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZDFLidiVPfd for ; Sat, 3 Mar 2012 08:19:42 -0800 (PST) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB621F85A2 for ; Sat, 3 Mar 2012 08:19:41 -0800 (PST) Received: from host86-163-139-217.range86-163.btcentralplus.com (HELO pc6) ([86.163.139.217]) by c2bthomr14.btconnect.com with SMTP id GMX21045; Sat, 03 Mar 2012 16:19:39 +0000 (GMT) Message-ID: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Andy Bierman" , "NETMOD Working Group" References: <4F4E9559.2000008@netconfcentral.org> Date: Sat, 3 Mar 2012 15:54:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F52449B.003A, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.3.153315:17:7.944, ip=86.163.139.217, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4F52449B.014B,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 16:19:43 -0000 ----- Original Message ----- From: "Andy Bierman" To: "NETMOD Working Group" Sent: Wednesday, February 29, 2012 10:15 PM > Hi, > > I was trying to update the modules on netconfcentral.org, and yangdump > is complaining about ietf-routing.yang. 1 fatal error and some warnings. > > unique "interfaces/interface/name"; > > Error: list node (interface) within unique stmt 'interfaces/interface/name' for node 'interfaces/interface/name' > ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node > > > A unique-stmt for container/list/leaf is not allowed. Only container and leaf are allowed. > RFC 6020 may not be clear on this. Martin should fix it ;-) Andy This did come up on the list 26-aug-08 when Martin replied to you "In our DML we could only express uniqueness for leafs within a list entry. But consider this (simplified) case, where an interface has a list of addresses: list interface { ... list address { ... leaf ip { type inet:ipv4address; } } } I want to say that all values of 'ip' must be unique across all interfaces: list interface { ... unique "address/ip"; ... } " Tom Petch > It can work if there is only 1 node in the 'uniqueness tuple and only 1 list in the path. > But except for that special case, list cannot deterministically produce a set of instances > that belong to the same tuple, for comparison to another tuple. > > If I comment out the unique-stmt, then I get these warnings from ipv4 and ipv6 modules: > > Warning: sibling object 'address' already defined in module 'ietf-ipv4-unicast-routing' at line 85 > ietf-ipv6-unicast-routing.yang:93.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 > ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 > ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 > ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'outgoing-interface' already defined in module 'ietf-routing' at line 132 > ietf-routing.yang:132.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'dest-prefix' already defined in module 'ietf-ipv4-unicast-routing' at line 63 > ietf-ipv6-unicast-routing.yang:71.5: warning(425): duplicate sibling node name from external augment > > Warning: sibling object 'next-hop' already defined in module 'ietf-ipv4-unicast-routing' at line 68 > ietf-ipv6-unicast-routing.yang:76.5: warning(425): duplicate sibling node name from external augment > > These warnings are because each module does an external augment on > the same target, using the same 'route-content' grouping. So all siblings > have duplicate local-names in different namespaces. > > I really think it sets a bad precedent to intentionally cause local-name > collisions -- to be as XML namespace dependent as possible. > The user-friendly thing to do would be to always add your own sub-container. > This is how CLI keeps things straight. E.g.: > (note container insertion before 'uses route-content') > > > augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" > + "rt:routes/rt:route" { > when "../../rt:address-family='ipV4' and " > + "../../rt:safi='nlri-unicast'" { > description > "This augment is valid only for IPv4 unicast."; > } > description > "This augment defines the content of IPv4 unicast routes."; > > container ipv4-unicast { > uses route-content; > } > } > > augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" > + "rt:routes/rt:route" { > when "../../rt:address-family='ipV6' and " > + "../../rt:safi='nlri-unicast'" { > description > "This augment is valid only for IPv6 unicast."; > } > description > "This augment defines the content of IPv6 unicast routes."; > container ipv6-unicast { > uses route-content; > } > } > } > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From andy@netconfcentral.org Sat Mar 3 08:56:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AB321F868C for ; Sat, 3 Mar 2012 08:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frMSfw+wVfsh for ; Sat, 3 Mar 2012 08:56:23 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 43E8521F866E for ; Sat, 3 Mar 2012 08:56:22 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q23GuLxC012713 for ; Sat, 3 Mar 2012 11:56:21 -0500 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:57051] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 00/8F-24163-53D425F4; Sat, 03 Mar 2012 11:56:21 -0500 Message-ID: <4F524D41.9020700@netconfcentral.org> Date: Sat, 03 Mar 2012 08:56:33 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "t.petch" References: <4F4E9559.2000008@netconfcentral.org> <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> In-Reply-To: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 16:56:24 -0000 On 03/03/2012 06:54 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "NETMOD Working Group" > Sent: Wednesday, February 29, 2012 10:15 PM > >> Hi, >> >> I was trying to update the modules on netconfcentral.org, and yangdump >> is complaining about ietf-routing.yang. 1 fatal error and some warnings. >> >> unique "interfaces/interface/name"; >> >> Error: list node (interface) within unique stmt > 'interfaces/interface/name' for node 'interfaces/interface/name' >> ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node >> >> >> A unique-stmt for container/list/leaf is not allowed. Only container and leaf > are allowed. >> RFC 6020 may not be clear on this. Martin should fix it ;-) > > Andy > > This did come up on the list 26-aug-08 when Martin replied to you > Martin is the one who recently told me that list was not allowed, and they did not support it in confd. I'll wait until he gets back from vacation to weigh in, before I release yuma 2.2-2. If the WG consensus is to allow a tuple node to be a node-set instead of a leaf value, then I'll change yangdump and netconfd to support that. If so, then the RFC needs some Errata added. Even though the unique-stmt is not technically XPath, I agree it might be confusing if XPath comparison rules were not used here, but the term 'unique' is not clearly defined in the current RFC text. > "In our DML we could only express uniqueness for leafs within a list > entry. But consider this (simplified) case, where an interface has a > list of addresses: > list interface { > ... > list address { > ... > leaf ip { type inet:ipv4address; } > } > } > > I want to say that all values of 'ip' must be unique across all > interfaces: > list interface { > ... > unique "address/ip"; > ... > } > > " > > Tom Petch > Andy From andy@netconfcentral.org Sun Mar 4 11:15:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E4321F8656 for ; Sun, 4 Mar 2012 11:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tARxyQYMqvLU for ; Sun, 4 Mar 2012 11:15:04 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0D21F8587 for ; Sun, 4 Mar 2012 11:15:03 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q24JF2jR019512 for ; Sun, 4 Mar 2012 14:15:02 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:60492] helo=[192.168.0.9]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 64/C8-09323-53FB35F4; Sun, 04 Mar 2012 14:15:02 -0500 Message-ID: <4F53BF42.5090004@netconfcentral.org> Date: Sun, 04 Mar 2012 11:15:14 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "t.petch" References: <4F4E9559.2000008@netconfcentral.org> <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> In-Reply-To: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 19:15:04 -0000 ... > > This did come up on the list 26-aug-08 when Martin replied to you > FYI, Message posted to netmod WG in Feb. 2009 from Martin about list within unique-stmt... http://www.ietf.org/mail-archive/web/netmod/current/msg02083.html > Tom Petch > Andy From lhotka@cesnet.cz Sun Mar 4 12:01:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D742B21F862F for ; Sun, 4 Mar 2012 12:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI494HGv+k7C for ; Sun, 4 Mar 2012 12:01:01 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AC24A21F8628 for ; Sun, 4 Mar 2012 12:01:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A3F3F540663; Sun, 4 Mar 2012 21:00:57 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt9C1GEyz-kc; Sun, 4 Mar 2012 21:00:52 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1471F540024; Sun, 4 Mar 2012 21:00:52 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , "t.petch" In-Reply-To: <4F524D41.9020700@netconfcentral.org> References: <4F4E9559.2000008@netconfcentral.org> <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Andy Bierman , "t.petch" , NETMOD Working Group Date: Sun, 04 Mar 2012 21:00:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 20:01:02 -0000 On Sat, 03 Mar 2012 08:56:33 -0800, Andy Bierman wrote: > On 03/03/2012 06:54 AM, t.petch wrote: > > ----- Original Message ----- > > From: "Andy Bierman" > > To: "NETMOD Working Group" > > Sent: Wednesday, February 29, 2012 10:15 PM > > > >> Hi, > >> > >> I was trying to update the modules on netconfcentral.org, and yangdump > >> is complaining about ietf-routing.yang. 1 fatal error and some warnings. > >> > >> unique "interfaces/interface/name"; > >> > >> Error: list node (interface) within unique stmt > > 'interfaces/interface/name' for node 'interfaces/interface/name' > >> ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node > >> > >> > >> A unique-stmt for container/list/leaf is not allowed. Only container and leaf > > are allowed. > >> RFC 6020 may not be clear on this. Martin should fix it ;-) > > > > Andy > > > > This did come up on the list 26-aug-08 when Martin replied to you > > > > Martin is the one who recently told me that list was not allowed, > and they did not support it in confd. I'll wait until he gets > back from vacation to weigh in, before I release yuma 2.2-2. Yes, let's wait for Martin's opinion. > If the WG consensus is to allow a tuple node to be a node-set > instead of a leaf value, then I'll change yangdump and netconfd > to support that. If so, then the RFC needs some Errata added. > > Even though the unique-stmt is not technically XPath, > I agree it might be confusing if XPath comparison rules > were not used here, but the term 'unique' is not clearly defined > in the current RFC text. The advantage of having 'unique' defined via XPath (as in 6110) is that it is a formal expression rather than prose, any particular instance document can be tested against it (using Schematron or just XSLT), and that definition - works as expected for the no-sublist case, - works for the use case in the routing module: list of sublists, one node in the tuple. - is well-defined for all other cases. Lada > > > > "In our DML we could only express uniqueness for leafs within a list > > entry. But consider this (simplified) case, where an interface has a > > list of addresses: > > list interface { > > ... > > list address { > > ... > > leaf ip { type inet:ipv4address; } > > } > > } > > > > I want to say that all values of 'ip' must be unique across all > > interfaces: > > list interface { > > ... > > unique "address/ip"; > > ... > > } > > > > " > > > > Tom Petch > > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Sun Mar 4 13:18:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4C21F860B for ; Sun, 4 Mar 2012 13:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwU3BTNqzP8J for ; Sun, 4 Mar 2012 13:18:44 -0800 (PST) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1760921F8562 for ; Sun, 4 Mar 2012 13:18:44 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q24LIhVw011839 for ; Sun, 4 Mar 2012 16:18:43 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:60585] helo=[192.168.0.9]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C0/89-31061-23CD35F4; Sun, 04 Mar 2012 16:18:43 -0500 Message-ID: <4F53DC3F.4090702@netconfcentral.org> Date: Sun, 04 Mar 2012 13:18:55 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "t.petch" , NETMOD Working Group References: <4F4E9559.2000008@netconfcentral.org> <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:18:47 -0000 On 03/04/2012 12:00 PM, Ladislav Lhotka wrote: > On Sat, 03 Mar 2012 08:56:33 -0800, Andy Bierman wrote: >> On 03/03/2012 06:54 AM, t.petch wrote: >>> ----- Original Message ----- >>> From: "Andy Bierman" >>> To: "NETMOD Working Group" >>> Sent: Wednesday, February 29, 2012 10:15 PM >>> >>>> Hi, >>>> >>>> I was trying to update the modules on netconfcentral.org, and yangdump >>>> is complaining about ietf-routing.yang. 1 fatal error and some warnings. >>>> >>>> unique "interfaces/interface/name"; >>>> >>>> Error: list node (interface) within unique stmt >>> 'interfaces/interface/name' for node 'interfaces/interface/name' >>>> ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node >>>> >>>> >>>> A unique-stmt for container/list/leaf is not allowed. Only container and leaf >>> are allowed. >>>> RFC 6020 may not be clear on this. Martin should fix it ;-) >>> >>> Andy >>> >>> This did come up on the list 26-aug-08 when Martin replied to you >>> >> >> Martin is the one who recently told me that list was not allowed, >> and they did not support it in confd. I'll wait until he gets >> back from vacation to weigh in, before I release yuma 2.2-2. > > Yes, let's wait for Martin's opinion. > >> If the WG consensus is to allow a tuple node to be a node-set >> instead of a leaf value, then I'll change yangdump and netconfd >> to support that. If so, then the RFC needs some Errata added. >> >> Even though the unique-stmt is not technically XPath, >> I agree it might be confusing if XPath comparison rules >> were not used here, but the term 'unique' is not clearly defined >> in the current RFC text. > > The advantage of having 'unique' defined via XPath (as in 6110) is that it is a formal expression rather than prose, any particular instance document can be tested against it (using Schematron or just XSLT), and that definition > > - works as expected for the no-sublist case, > - works for the use case in the routing module: list of sublists, one node in the tuple. > - is well-defined for all other cases. > I think this could work. For tuple { A, B, C } there is XPath result Ri = { R(Ai), R(Bi), R(Ci) }, that can be compared to Rj = { R(Aj), R(Bj), R(Cj) }. A tuple is compared only if non-empty node-sets exist for all nodes (A, B and C). > Lada > Andy >> >> >>> "In our DML we could only express uniqueness for leafs within a list >>> entry. But consider this (simplified) case, where an interface has a >>> list of addresses: >>> list interface { >>> ... >>> list address { >>> ... >>> leaf ip { type inet:ipv4address; } >>> } >>> } >>> >>> I want to say that all values of 'ip' must be unique across all >>> interfaces: >>> list interface { >>> ... >>> unique "address/ip"; >>> ... >>> } >>> >>> " >>> >>> Tom Petch >>> >> >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Sun Mar 4 23:50:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4811E8083 for ; Sun, 4 Mar 2012 23:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5R5UyCb0bvJ for ; Sun, 4 Mar 2012 23:50:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A1FB611E8076 for ; Sun, 4 Mar 2012 23:50:20 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 7C6672A30AE; Mon, 5 Mar 2012 08:50:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330933818; bh=nkUeqv7Y58WM4kuyUeur91VlSBhRHDRHIAOnCeWm8mY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sypmNCjBTQvluoMXYtZZxEkmpALgH1lzdleqevrg+jrWVFL9J7V56L4PYT3LVId4K EZW0VI0Ff542XdpdZXj+A3O97QLcYZmr1DEy1wwlHWj4yKvFGVhotU2ilwCXKD86hf 2WCVsJrRV21ihUmBUUE6IZfKKbvV2z/vJy95/B6I= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: <4F53DC3F.4090702@netconfcentral.org> Date: Mon, 5 Mar 2012 08:50:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <374F0182-80FD-42D9-B13B-79987FF04042@nic.cz> References: <4F4E9559.2000008@netconfcentral.org> <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <4F53DC3F.4090702@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 07:50:21 -0000 On Mar 4, 2012, at 10:18 PM, Andy Bierman wrote: > On 03/04/2012 12:00 PM, Ladislav Lhotka wrote: >> On Sat, 03 Mar 2012 08:56:33 -0800, Andy = Bierman wrote: >>> On 03/03/2012 06:54 AM, t.petch wrote: >>>> ----- Original Message ----- >>>> From: "Andy Bierman" >>>> To: "NETMOD Working Group" >>>> Sent: Wednesday, February 29, 2012 10:15 PM >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I was trying to update the modules on netconfcentral.org, and = yangdump >>>>> is complaining about ietf-routing.yang. 1 fatal error and some = warnings. >>>>>=20 >>>>> unique "interfaces/interface/name"; >>>>>=20 >>>>> Error: list node (interface) within unique stmt >>>> 'interfaces/interface/name' for node 'interfaces/interface/name' >>>>> ietf-routing@2012-02-20.yang:185.7: error(352): invalid = unique-stmt node >>>>>=20 >>>>>=20 >>>>> A unique-stmt for container/list/leaf is not allowed. Only = container and leaf >>>> are allowed. >>>>> RFC 6020 may not be clear on this. Martin should fix it ;-) >>>>=20 >>>> Andy >>>>=20 >>>> This did come up on the list 26-aug-08 when Martin replied to you >>>>=20 >>>=20 >>> Martin is the one who recently told me that list was not allowed, >>> and they did not support it in confd. I'll wait until he gets >>> back from vacation to weigh in, before I release yuma 2.2-2. >>=20 >> Yes, let's wait for Martin's opinion. >>=20 >>> If the WG consensus is to allow a tuple node to be a node-set >>> instead of a leaf value, then I'll change yangdump and netconfd >>> to support that. If so, then the RFC needs some Errata added. >>>=20 >>> Even though the unique-stmt is not technically XPath, >>> I agree it might be confusing if XPath comparison rules >>> were not used here, but the term 'unique' is not clearly defined >>> in the current RFC text. >>=20 >> The advantage of having 'unique' defined via XPath (as in 6110) is = that it is a formal expression rather than prose, any particular = instance document can be tested against it (using Schematron or just = XSLT), and that definition >>=20 >> - works as expected for the no-sublist case, >> - works for the use case in the routing module: list of sublists, one = node in the tuple. >> - is well-defined for all other cases. >>=20 >=20 > I think this could work. > For tuple { A, B, C } there is XPath result Ri =3D { R(Ai), R(Bi), = R(Ci) }, > that can be compared to Rj =3D { R(Aj), R(Bj), R(Cj) }. > A tuple is compared only if non-empty node-sets exist for all nodes = (A, B and C). The definition can state that unique "A1 A2 =85 An" is equivalent to must "not(preceding-sibling::L [ A1 =3D current()/A1 and A2 =3D current()/A2 and =85 An =3D current()/An ])" where L is the parent 'list' node. Lada >=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>>=20 >>>> "In our DML we could only express uniqueness for leafs within a = list >>>> entry. But consider this (simplified) case, where an interface has = a >>>> list of addresses: >>>> list interface { >>>> ... >>>> list address { >>>> ... >>>> leaf ip { type inet:ipv4address; } >>>> } >>>> } >>>>=20 >>>> I want to say that all values of 'ip' must be unique across all >>>> interfaces: >>>> list interface { >>>> ... >>>> unique "address/ip"; >>>> ... >>>> } >>>>=20 >>>> " >>>>=20 >>>> Tom Petch >>>>=20 >>>=20 >>>=20 >>> Andy >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Mar 5 05:39:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E01121F870E for ; Mon, 5 Mar 2012 05:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wayyDZo93QRH for ; Mon, 5 Mar 2012 05:39:09 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01621F86B9 for ; Mon, 5 Mar 2012 05:39:09 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FDB01200D4D; Mon, 5 Mar 2012 14:39:08 +0100 (CET) Date: Mon, 05 Mar 2012 14:39:06 +0100 (CET) Message-Id: <20120305.143906.198953730820615646.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:39:10 -0000 Hi, Ladislav Lhotka wrote: > On Sat, 03 Mar 2012 08:56:33 -0800, Andy Bierman > wrote: > > On 03/03/2012 06:54 AM, t.petch wrote: > > > ----- Original Message ----- > > > From: "Andy Bierman" > > > To: "NETMOD Working Group" > > > Sent: Wednesday, February 29, 2012 10:15 PM > > > > > >> Hi, > > >> > > >> I was trying to update the modules on netconfcentral.org, and yangdump > > >> is complaining about ietf-routing.yang. 1 fatal error and some > > >> warnings. > > >> > > >> unique "interfaces/interface/name"; > > >> > > >> Error: list node (interface) within unique stmt > > > 'interfaces/interface/name' for node 'interfaces/interface/name' > > >> ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt > > >> node > > >> > > >> > > >> A unique-stmt for container/list/leaf is not allowed. Only container > > >> and leaf > > > are allowed. > > >> RFC 6020 may not be clear on this. Martin should fix it ;-) > > > > > > Andy > > > > > > This did come up on the list 26-aug-08 when Martin replied to you > > > > > > > Martin is the one who recently told me that list was not allowed, > > and they did not support it in confd. I'll wait until he gets > > back from vacation to weigh in, before I release yuma 2.2-2. > > Yes, let's wait for Martin's opinion. Andy is correct that we don't support sublists in the unique expression in our NETCONF server. However, I do agree with what you write: > The advantage of having 'unique' defined via XPath (as in 6110) is > that it is a formal expression rather than prose, any particular > instance document can be tested against it (using Schematron or just > XSLT), and that definition > > - works as expected for the no-sublist case, > - works for the use case in the routing module: list of sublists, one > - node in the tuple. > - is well-defined for all other cases. The problem is that the text in 6020 is unclear. The text: "the combined values of all the leaf instances [...] MUST be unique" can be interpreted in different ways. OTOH, the WG has published two documents related to this, 6020 and 6110. 6020 in itself is unclear, but if you also read 6110, the interpretation is well-defined. So, we have two options. Either we say that with the two documents, the meaning is well-defined, or we say that since 6020 is unclear, we cannot publish any module that uses sublists in the unique statement. [In any case, I will try to fix my implementation to work as defined in 6110.] BTW, they got this right in XSD. We should have done something like: unique { [selector ;] // default is "current()" field ; ... field ; [error-message ;] [description ;] } Then we could also handle multiple keys in sublists: list router { unique { selector "interfaces/interface"; // assuming type and location were used instead of name field "type"; field "location"; } } The drawback is that this looks more complicated... /martin From lhotka@nic.cz Mon Mar 5 06:58:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9810B21F86F9 for ; Mon, 5 Mar 2012 06:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsV6E1TChaNP for ; Mon, 5 Mar 2012 06:58:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B361C21F8593 for ; Mon, 5 Mar 2012 06:58:37 -0800 (PST) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id AF51F2A30DC; Mon, 5 Mar 2012 15:58:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330959515; bh=FstNNX2u2+/kumv+Fr6Z72K1zXZ0B7yvrKGTOXOXAQc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EElshvFlGNB9SXjKVw/zrxMfi5pLi/3Gtu/0mih2B6yajHqP+vyUCVzaj9tlha7E1 sL8NTN9OgFSg6C4FeNlZpOR5eC8hJxazdhfVSeV18h1IyG8ITVOh16x7CBRo4vrJO+ 1jw2Hu5QZrnqfiCFisWsvuNfIY2LhUzfHfMp8XmI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120305.143906.198953730820615646.mbj@tail-f.com> Date: Mon, 5 Mar 2012 15:58:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72EB0B53-0E1A-4E67-81B7-148C1ED3B768@nic.cz> References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:58:38 -0000 On Mar 5, 2012, at 2:39 PM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> On Sat, 03 Mar 2012 08:56:33 -0800, Andy Bierman >> wrote: >>> On 03/03/2012 06:54 AM, t.petch wrote: >>>> ----- Original Message ----- >>>> From: "Andy Bierman" >>>> To: "NETMOD Working Group" >>>> Sent: Wednesday, February 29, 2012 10:15 PM >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I was trying to update the modules on netconfcentral.org, and = yangdump >>>>> is complaining about ietf-routing.yang. 1 fatal error and some >>>>> warnings. >>>>>=20 >>>>> unique "interfaces/interface/name"; >>>>>=20 >>>>> Error: list node (interface) within unique stmt >>>> 'interfaces/interface/name' for node 'interfaces/interface/name' >>>>> ietf-routing@2012-02-20.yang:185.7: error(352): invalid = unique-stmt >>>>> node >>>>>=20 >>>>>=20 >>>>> A unique-stmt for container/list/leaf is not allowed. Only = container >>>>> and leaf >>>> are allowed. >>>>> RFC 6020 may not be clear on this. Martin should fix it ;-) >>>>=20 >>>> Andy >>>>=20 >>>> This did come up on the list 26-aug-08 when Martin replied to you >>>>=20 >>>=20 >>> Martin is the one who recently told me that list was not allowed, >>> and they did not support it in confd. I'll wait until he gets >>> back from vacation to weigh in, before I release yuma 2.2-2. >>=20 >> Yes, let's wait for Martin's opinion. >=20 > Andy is correct that we don't support sublists in the unique > expression in our NETCONF server. However, I do agree with what you > write: >=20 >> The advantage of having 'unique' defined via XPath (as in 6110) is >> that it is a formal expression rather than prose, any particular >> instance document can be tested against it (using Schematron or just >> XSLT), and that definition >>=20 >> - works as expected for the no-sublist case, >> - works for the use case in the routing module: list of sublists, one >> - node in the tuple. >> - is well-defined for all other cases. >=20 > The problem is that the text in 6020 is unclear. The text: >=20 > "the combined values of all the leaf instances [...] MUST be unique" >=20 > can be interpreted in different ways. >=20 > OTOH, the WG has published two documents related to this, 6020 and > 6110. 6020 in itself is unclear, but if you also read 6110, the > interpretation is well-defined. >=20 > So, we have two options. Either we say that with the two documents, > the meaning is well-defined, or we say that since 6020 is unclear, we > cannot publish any module that uses sublists in the unique statement. I prefer the first option. I am not sure if it is acceptable, but an = erratum could be added to 6020 with a reference to the corresponding = section in 6110. >=20 > [In any case, I will try to fix my implementation to work as defined > in 6110.] >=20 > BTW, they got this right in XSD. We should have done something like: >=20 > unique { > [selector ;] // default is "current()" > field ; > ... > field ; > [error-message ;] > [description ;] > } So, essentially, 'unique' in YANG is restricted to having "current()" as = the selector. If necessary, constraints involving other selectors can be = defined using 'must'. BTW, the possibility of specifying an = 'error-message' would indeed be useful. Lada >=20 > Then we could also handle multiple keys in sublists: >=20 > list router { > unique { > selector "interfaces/interface"; > // assuming type and location were used instead of name > field "type"; > field "location"; > } > } >=20 > The drawback is that this looks more complicated... =20 >=20 >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Mon Mar 5 08:10:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D7121F8589 for ; Mon, 5 Mar 2012 08:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGEq8VDE2G8U for ; Mon, 5 Mar 2012 08:10:35 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id EA60321F8577 for ; Mon, 5 Mar 2012 08:10:34 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25GAXau029277 for ; Mon, 5 Mar 2012 11:10:34 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36331] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 64/8D-32269-875E45F4; Mon, 05 Mar 2012 11:10:33 -0500 Message-ID: <4F54E585.3020507@netconfcentral.org> Date: Mon, 05 Mar 2012 08:10:45 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Bjorklund References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> In-Reply-To: <20120305.143906.198953730820615646.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 16:10:36 -0000 On 03/05/2012 05:39 AM, Martin Bjorklund wrote: ... > The problem is that the text in 6020 is unclear. The text: > > "the combined values of all the leaf instances [...] MUST be unique" > > can be interpreted in different ways. > > OTOH, the WG has published two documents related to this, 6020 and > 6110. 6020 in itself is unclear, but if you also read 6110, the > interpretation is well-defined. > > So, we have two options. Either we say that with the two documents, > the meaning is well-defined, or we say that since 6020 is unclear, we > cannot publish any module that uses sublists in the unique statement. > I don't think it is a good idea to declare 6020 "fixed" by 6110. Tools conforming to 6020 should not be made instantly non-compliant because the spec is silent on an issue. A future version of YANG can declare this fixed, but not 6020. > [In any case, I will try to fix my implementation to work as defined > in 6110.] > > BTW, they got this right in XSD. We should have done something like: > > unique { > [selector;] // default is "current()" > field; > ... > field; > [error-message;] > [description;] > } > > Then we could also handle multiple keys in sublists: > > list router { > unique { > selector "interfaces/interface"; > // assuming type and location were used instead of name > field "type"; > field "location"; > } > } Why can't I just do: unique "interfaces/interface/type interfaces/interface/location"; The nodes in the unique tuple become completely unrelated in your new interpretation of unique-stmt. There is no attempt to correlate keys. Attempts to make sure type and location are from the same list entry are not possible with the YANG unique-stmt. > > The drawback is that this looks more complicated... > It allows more arbitrary placement of the unique-stmt, which is more complicated and may not provide much more real utility. IMO the new interpretation of unique-stmt can cause more problems than it solves. Potential for garbage-in/garbage-out is very high. Tools will not be able to analyze the intent, so only XPath experts will get this right. > > > > /martin > > Andy From andy@netconfcentral.org Mon Mar 5 08:45:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9421F87AD for ; Mon, 5 Mar 2012 08:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifyLcqnZY9mE for ; Mon, 5 Mar 2012 08:45:56 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9421F87A2 for ; Mon, 5 Mar 2012 08:45:56 -0800 (PST) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25Gjsr0008539 for ; Mon, 5 Mar 2012 11:45:54 -0500 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36535] helo=[192.168.0.9]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C0/51-23992-1CDE45F4; Mon, 05 Mar 2012 11:45:54 -0500 Message-ID: <4F54EDCE.5010105@netconfcentral.org> Date: Mon, 05 Mar 2012 08:46:06 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> <72EB0B53-0E1A-4E67-81B7-148C1ED3B768@nic.cz> In-Reply-To: <72EB0B53-0E1A-4E67-81B7-148C1ED3B768@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 16:45:57 -0000 On 03/05/2012 06:58 AM, Ladislav Lhotka wrote: ... >> So, we have two options. Either we say that with the two documents, >> the meaning is well-defined, or we say that since 6020 is unclear, we >> cannot publish any module that uses sublists in the unique statement. > > I prefer the first option. I am not sure if it is acceptable, but an erratum could be added to 6020 with a reference to the corresponding section in 6110. > I don't think 6020 is clear at all about this, and so nested list should not be allowed for 6020 implementations. The reason is that this YANG unique-stmt only works (for nested lists) when there is 1 node in the tuple. Users who don't know XPath will get it wrong (not aware of XPath node-set compare rules) and XPath experts will assume it works like xsd:unique, but it doesn't. Selecting 2 siblings from the same nested list entry is far different than selecting 1 field from entries { 1, 3, 5 } and another field from { 3, 10, 20 }. This is going to produce garbage results. >> >> [In any case, I will try to fix my implementation to work as defined >> in 6110.] >> >> BTW, they got this right in XSD. We should have done something like: >> >> unique { >> [selector;] // default is "current()" >> field; >> ... >> field; >> [error-message;] >> [description;] >> } > In a future version of YANG, unique-stmt can be changed to allow lists, and add 1 or more 'field-stmt' to pick siblings from the same target. > So, essentially, 'unique' in YANG is restricted to having "current()" as the selector. If necessary, constraints involving other selectors can be defined using 'must'. BTW, the possibility of specifying an 'error-message' would indeed be useful. > Only for 1 node. For 2 or more, the behavior is not the same as XPath. IMO that problem should not be ignored. > Lada Andy > >> >> Then we could also handle multiple keys in sublists: >> >> list router { >> unique { >> selector "interfaces/interface"; >> // assuming type and location were used instead of name >> field "type"; >> field "location"; >> } >> } >> >> The drawback is that this looks more complicated... >> >> >> >> >> /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > > From andy@netconfcentral.org Mon Mar 5 09:21:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729A021F876E for ; Mon, 5 Mar 2012 09:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78vw5-v2Myc0 for ; Mon, 5 Mar 2012 09:21:10 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 9E82121F8768 for ; Mon, 5 Mar 2012 09:21:05 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25HL4bg029386 for ; Mon, 5 Mar 2012 12:21:04 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36585] helo=[192.168.0.9]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3B/49-25783-FF5F45F4; Mon, 05 Mar 2012 12:21:04 -0500 Message-ID: <4F54F60C.5030309@netconfcentral.org> Date: Mon, 05 Mar 2012 09:21:16 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> <72EB0B53-0E1A-4E67-81B7-148C1ED3B768@nic.cz> In-Reply-To: <72EB0B53-0E1A-4E67-81B7-148C1ED3B768@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:21:10 -0000 .. >> >> Then we could also handle multiple keys in sublists: >> >> list router { >> unique { >> selector "interfaces/interface"; >> // assuming type and location were used instead of name >> field "type"; >> field "location"; >> } >> } >> >> The drawback is that this looks more complicated... >> list top { description "demonstrate that unique-stmt with a nested list is broken if there are 2+ nodes instead of 1"; key a; // same pair { x, y } can only be used once unique "pair/x pair/y"; leaf a { type int32; } list pair { key id; leaf id { type int32; } leaf x { type int32; } leaf y { type int32; } } // a=1: pair 1,1 top { a 1 pair { id 1 x 1 y 1 } } // a=2: 2 incomplete pair entries combine to form point 1,1 top { a 2 pair { id 1 x 1 } pair { id 2 y 1 } } U(1) = { 1, 1 } U(2) = { 1, 1 } The intent is that only complete { x, y } pairs be checked in the unique-stmt test, but that is not what YANG unique-stmt does. An error is incorrectly generated in this scenario. >> >> >> >> /martin > Andy From mbj@tail-f.com Mon Mar 5 09:52:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD7B21F8775 for ; Mon, 5 Mar 2012 09:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNjCqpOxMLkS for ; Mon, 5 Mar 2012 09:52:02 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1121F87CB for ; Mon, 5 Mar 2012 09:52:02 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6BAFC1200D57; Mon, 5 Mar 2012 18:52:00 +0100 (CET) Date: Mon, 05 Mar 2012 18:51:59 +0100 (CET) Message-Id: <20120305.185159.505003480.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F54E585.3020507@netconfcentral.org> References: <20120305.143906.198953730820615646.mbj@tail-f.com> <4F54E585.3020507@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:52:02 -0000 Andy Bierman wrote: > On 03/05/2012 05:39 AM, Martin Bjorklund wrote: > ... > > The problem is that the text in 6020 is unclear. The text: > > > > "the combined values of all the leaf instances [...] MUST be unique" > > > > can be interpreted in different ways. > > > > OTOH, the WG has published two documents related to this, 6020 and > > 6110. 6020 in itself is unclear, but if you also read 6110, the > > interpretation is well-defined. > > > > So, we have two options. Either we say that with the two documents, > > the meaning is well-defined, or we say that since 6020 is unclear, we > > cannot publish any module that uses sublists in the unique statement. > > > > I don't think it is a good idea to declare 6020 "fixed" by 6110. > Tools conforming to 6020 should not be made instantly non-compliant > because the spec is silent on an issue. > > A future version of YANG can declare this fixed, but not 6020. > > > [In any case, I will try to fix my implementation to work as defined > > in 6110.] > > > > BTW, they got this right in XSD. We should have done something like: > > > > unique { > > [selector;] // default is "current()" > > field; > > ... > > field; > > [error-message;] > > [description;] > > } > > > > Then we could also handle multiple keys in sublists: > > > > list router { > > unique { > > selector "interfaces/interface"; > > // assuming type and location were used instead of name > > field "type"; > > field "location"; > > } > > } > > Why can't I just do: > > unique "interfaces/interface/type interfaces/interface/location"; > > The nodes in the unique tuple become completely unrelated in your > new interpretation > of unique-stmt. There is no attempt to correlate keys. Attempts to > make sure type and location are from the same list entry are not possible > with the YANG unique-stmt. Exactly. That's why a new statement like the one above is needed. > > The drawback is that this looks more complicated... > > > > It allows more arbitrary placement of the unique-stmt, which is more > complicated > and may not provide much more real utility. > > IMO the new interpretation of unique-stmt can cause more problems > than it solves. Potential for garbage-in/garbage-out is very high. > Tools will not be able to analyze the intent, so only XPath experts > will get this right. Actually, I think it is the other way around. Without it, you need to write the explicit low-level XPath expression in a must statement, instead of the high-level unique statement. /martin From ietfc@btconnect.com Mon Mar 5 09:58:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390E821F88AE for ; Mon, 5 Mar 2012 09:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_50=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk0ZK4cFuiaq for ; Mon, 5 Mar 2012 09:58:33 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 222C321F88A3 for ; Mon, 5 Mar 2012 09:58:32 -0800 (PST) Received: from host86-163-139-217.range86-163.btcentralplus.com (HELO pc6) ([86.163.139.217]) by c2beaomr06.btconnect.com with SMTP id GSV31777; Mon, 05 Mar 2012 17:58:27 +0000 (GMT) Message-ID: <015201ccfaf1$19e1ea00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ladislav Lhotka" , "Andy Bierman" References: <4F4E9559.2000008@netconfcentral.org> <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> Date: Mon, 5 Mar 2012 17:57:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F54FEC2.009C, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.5.171225:17:7.944, ip=86.163.139.217, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4F54FEC3.0060,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:58:34 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Andy Bierman" ; "t.petch" Cc: "NETMOD Working Group" Sent: Sunday, March 04, 2012 9:00 PM > On Sat, 03 Mar 2012 08:56:33 -0800, Andy Bierman wrote: > > On 03/03/2012 06:54 AM, t.petch wrote: > > > ----- Original Message ----- > > > From: "Andy Bierman" > > > To: "NETMOD Working Group" > > > Sent: Wednesday, February 29, 2012 10:15 PM > > > > > >> Hi, > > >> > > >> I was trying to update the modules on netconfcentral.org, and yangdump > > >> is complaining about ietf-routing.yang. 1 fatal error and some warnings. > > >> > > >> unique "interfaces/interface/name"; > > >> > > >> Error: list node (interface) within unique stmt > > > 'interfaces/interface/name' for node 'interfaces/interface/name' > > >> ietf-routing@2012-02-20.yang:185.7: error(352): invalid unique-stmt node > > >> > > >> > > >> A unique-stmt for container/list/leaf is not allowed. Only container and leaf > > > are allowed. > > >> RFC 6020 may not be clear on this. Martin should fix it ;-) > > > > > > Andy > > > > > > This did come up on the list 26-aug-08 when Martin replied to you > > > > > > > Martin is the one who recently told me that list was not allowed, > > and they did not support it in confd. I'll wait until he gets > > back from vacation to weigh in, before I release yuma 2.2-2. > > Yes, let's wait for Martin's opinion. > > > If the WG consensus is to allow a tuple node to be a node-set > > instead of a leaf value, then I'll change yangdump and netconfd > > to support that. If so, then the RFC needs some Errata added. > > > > Even though the unique-stmt is not technically XPath, > > I agree it might be confusing if XPath comparison rules > > were not used here, but the term 'unique' is not clearly defined > > in the current RFC text. > > The advantage of having 'unique' defined via XPath (as in 6110) is that it is a formal expression rather than prose, any particular instance document can be tested against it (using Schematron or just XSLT), and that definition Lada And the disadvantage? Remember all those lovely discussions we had about the use of XPath in draft-ietf-netmod-yang, in 2008, all that versioning, contexts, interpretation .... I am older and wiser but not sure of reaching a conclusion any quicker than we did then. It is a lot of work if we can do it more simply in plain English:-) Tom Petch > - works as expected for the no-sublist case, > - works for the use case in the routing module: list of sublists, one node in the tuple. > - is well-defined for all other cases. > > Lada > > > > > From andy@netconfcentral.org Mon Mar 5 10:10:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD9921F87A7 for ; Mon, 5 Mar 2012 10:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83AGMrh--asL for ; Mon, 5 Mar 2012 10:10:08 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3761621F87EE for ; Mon, 5 Mar 2012 10:10:08 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25IA630021168 for ; Mon, 5 Mar 2012 13:10:07 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36674] helo=[192.168.0.9]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 07/D1-25783-D71055F4; Mon, 05 Mar 2012 13:10:06 -0500 Message-ID: <4F55018A.9090908@netconfcentral.org> Date: Mon, 05 Mar 2012 10:10:18 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Bjorklund References: <20120305.143906.198953730820615646.mbj@tail-f.com> <4F54E585.3020507@netconfcentral.org> <20120305.185159.505003480.mbj@tail-f.com> In-Reply-To: <20120305.185159.505003480.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:10:09 -0000 .. > Actually, I think it is the other way around. Without it, you need to > write the explicit low-level XPath expression in a must statement, > instead of the high-level unique statement. > If only the YANG unique-stmt actually worked for node-sets if N > 1. The must-stmt would be rather complex to make sure the tuple being compared came from the same nested list entries. I challenge you to find a use-case where it doesn't matter if pairs are incorrectly formed from different list instances. The XPath Lada generates is all very nice, but logical-AND of N unrelated node-set comparisons is not semantically useful. There is a reason the xsd:unique statement is constrained to pick N fields from the same context node. Doing otherwise produces garbage results. IMO, it is not really worth it to have some CLRs for unique-stmt, like lists are OK for 1 node in the unique-stmt only. > > /martin > > Andy From mbj@tail-f.com Mon Mar 5 10:44:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587CE21F88FF for ; Mon, 5 Mar 2012 10:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTZlIJ5vE7Kf for ; Mon, 5 Mar 2012 10:44:13 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B65AA21F8907 for ; Mon, 5 Mar 2012 10:44:13 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 994B31200D4D; Mon, 5 Mar 2012 19:44:12 +0100 (CET) Date: Mon, 05 Mar 2012 19:44:11 +0100 (CET) Message-Id: <20120305.194411.335944913.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F55018A.9090908@netconfcentral.org> References: <4F54E585.3020507@netconfcentral.org> <20120305.185159.505003480.mbj@tail-f.com> <4F55018A.9090908@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:44:14 -0000 Andy Bierman wrote: > .. > > Actually, I think it is the other way around. Without it, you need to > > write the explicit low-level XPath expression in a must statement, > > instead of the high-level unique statement. > > > > If only the YANG unique-stmt actually worked for node-sets if N > 1. > The must-stmt would be rather complex to make sure the tuple being > compared came from the same nested list entries. I challenge you > to find a use-case where it doesn't matter if pairs are incorrectly > formed from different list instances. No need to challenge; I agree. > The XPath Lada generates > is all very nice, but logical-AND of N unrelated node-set comparisons is > not semantically useful. Agreed. > There is a reason the xsd:unique statement is constrained to > pick N fields from the same context node. Doing otherwise > produces garbage results. Agreed. > IMO, it is not really worth it to have some CLRs for unique-stmt, > like lists are OK for 1 node in the unique-stmt only. That was also my opinion earlier, when I told you that sublists were not allowed. But Lada's solution is very elegant. It provides an unambigous interpretation of the unique statement. Quoting from his email: - works as expected for the no-sublist case, - works for the use case in the routing module: list of sublists, one node in the tuple. - is well-defined for all other cases. Note the last bullet. With Lada's interpretation, we wouldn't need to have this debates of what the meaning of a certain unique expression is. /martin From andy@netconfcentral.org Mon Mar 5 11:06:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7198F21F8879 for ; Mon, 5 Mar 2012 11:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOkHoD7UxZPK for ; Mon, 5 Mar 2012 11:06:06 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5B21F8870 for ; Mon, 5 Mar 2012 11:06:06 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25J65kf007333 for ; Mon, 5 Mar 2012 14:06:05 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36854] helo=[192.168.0.9]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 87/4A-25783-C9E055F4; Mon, 05 Mar 2012 14:06:04 -0500 Message-ID: <4F550EA8.8050008@netconfcentral.org> Date: Mon, 05 Mar 2012 11:06:16 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Bjorklund References: <4F54E585.3020507@netconfcentral.org> <20120305.185159.505003480.mbj@tail-f.com> <4F55018A.9090908@netconfcentral.org> <20120305.194411.335944913.mbj@tail-f.com> In-Reply-To: <20120305.194411.335944913.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:06:07 -0000 On 03/05/2012 10:44 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> .. >>> Actually, I think it is the other way around. Without it, you need to >>> write the explicit low-level XPath expression in a must statement, >>> instead of the high-level unique statement. >>> >> >> If only the YANG unique-stmt actually worked for node-sets if N> 1. >> The must-stmt would be rather complex to make sure the tuple being >> compared came from the same nested list entries. I challenge you >> to find a use-case where it doesn't matter if pairs are incorrectly >> formed from different list instances. > > No need to challenge; I agree. > >> The XPath Lada generates >> is all very nice, but logical-AND of N unrelated node-set comparisons is >> not semantically useful. > > Agreed. > >> There is a reason the xsd:unique statement is constrained to >> pick N fields from the same context node. Doing otherwise >> produces garbage results. > > Agreed. > >> IMO, it is not really worth it to have some CLRs for unique-stmt, >> like lists are OK for 1 node in the unique-stmt only. > > That was also my opinion earlier, when I told you that sublists were > not allowed. But Lada's solution is very elegant. It provides an > unambigous interpretation of the unique statement. Quoting from his > email: > > - works as expected for the no-sublist case, > - works for the use case in the routing module: list of sublists, > one node in the tuple. > - is well-defined for all other cases. > > Note the last bullet. With Lada's interpretation, we wouldn't need to > have this debates of what the meaning of a certain unique expression > is. > This is a straw-man, because we could just as easily decide that RFC 6020 does not support nested lists and be done with it. I am concerned that the only use-case for multiple nodes is to compare them from the same context node, and that is not what YANG does. A little bullet in an RFC Errata is not going to remove that confusion. Being 'well-defined' to do the wrong thing is not that compelling to me. > > /martin > > Andy From lhotka@nic.cz Mon Mar 5 11:46:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3353D21F8967 for ; Mon, 5 Mar 2012 11:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGNz5eGuPe9h for ; Mon, 5 Mar 2012 11:46:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 80CE021F893D for ; Mon, 5 Mar 2012 11:46:48 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id B1CE92A007D; Mon, 5 Mar 2012 20:46:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330976807; bh=XWs6RgzmIx0QL4JMcui7VMgB8BxWDklCnph/re2KCvw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N/mxgFQkL1OAPZhxG0RyirbOtQ+F4+eYGzEPsc025I0oG4if2rxXQE4lhGyytjzQm OasB1usVLnd+8MicqxD3YvhgtSImILZVEmNnUtux4ZuqDYRqlahCftdcmboBK72zx5 dOFmIN/H9NXgzBcwTaMqiIDW6lM7timZ3Ix9FWek= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <015201ccfaf1$19e1ea00$4001a8c0@gateway.2wire.net> Date: Mon, 5 Mar 2012 20:46:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1815001B-3F40-45DD-B1C7-1EB90327D26A@nic.cz> References: <4F4E9559.2000008@netconfcentral.org> <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <015201ccfaf1$19e1ea00$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: NETMOD Working Group Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:46:49 -0000 On Mar 5, 2012, at 5:57 PM, t.petch wrote: > And the disadvantage? Remember all those lovely discussions we had = about the > use of XPath in draft-ietf-netmod-yang, in 2008, all that versioning, = contexts, > interpretation .... I am older and wiser but not sure of reaching a = conclusion > any quicker than we did then. Yes, it was difficult but in fact eventually we did solve all the XPath = issues back then! >=20 > It is a lot of work if we can do it more simply in plain English:-) Ideally, we can have both (in accord, of course:-). I think it is pretty = much the same as a textual description of syntax versus ABNF. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Mar 5 11:57:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14BE11E8076 for ; Mon, 5 Mar 2012 11:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkq8HmDyn-e3 for ; Mon, 5 Mar 2012 11:57:01 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0707711E8075 for ; Mon, 5 Mar 2012 11:57:01 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 312732A007D; Mon, 5 Mar 2012 20:57:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330977420; bh=Dmiy3ODJer81ybcRsUTewCP5mhVaR1TjU2vw98J1QU8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x6nw4Zpk7PxC0vX3ZcpM9Qw1LvP+XN4oJ2hsY427TBYZAQnnCukyMGuPpDkcrJrbq 3jjOVHrxXLfaQSm3WrUulb97Ll3Tt/UHmdYBkSbHBnPqOAs7/CHWSDDU3wVJj8vjYK Wwj6cDp74s9B1VYTr7S9dCBfGs1WcmcsRcgdtalE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F54E585.3020507@netconfcentral.org> Date: Mon, 5 Mar 2012 20:56:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz> References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> <4F54E585.3020507@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:57:02 -0000 On Mar 5, 2012, at 5:10 PM, Andy Bierman wrote: > On 03/05/2012 05:39 AM, Martin Bjorklund wrote: > ... >> The problem is that the text in 6020 is unclear. The text: >>=20 >> "the combined values of all the leaf instances [...] MUST be = unique" >>=20 >> can be interpreted in different ways. >>=20 >> OTOH, the WG has published two documents related to this, 6020 and >> 6110. 6020 in itself is unclear, but if you also read 6110, the >> interpretation is well-defined. >>=20 >> So, we have two options. Either we say that with the two documents, >> the meaning is well-defined, or we say that since 6020 is unclear, we >> cannot publish any module that uses sublists in the unique statement. >>=20 >=20 > I don't think it is a good idea to declare 6020 "fixed" by 6110. > Tools conforming to 6020 should not be made instantly non-compliant > because the spec is silent on an issue. Thing is, the text in 6020 is unclear and ambiguous, and apparently = there are already different tools that behave differently. This should = certainly be avoided. >=20 > A future version of YANG can declare this fixed, but not 6020. >=20 >> [In any case, I will try to fix my implementation to work as defined >> in 6110.] >>=20 >> BTW, they got this right in XSD. We should have done something like: >>=20 >> unique { >> [selector;] // default is "current()" >> field; >> ... >> field; >> [error-message;] >> [description;] >> } >>=20 >> Then we could also handle multiple keys in sublists: >>=20 >> list router { >> unique { >> selector "interfaces/interface"; >> // assuming type and location were used instead of name >> field "type"; >> field "location"; >> } >> } >=20 > Why can't I just do: >=20 > unique "interfaces/interface/type interfaces/interface/location"; >=20 > The nodes in the unique tuple become completely unrelated in your new = interpretation > of unique-stmt. There is no attempt to correlate keys. Attempts to > make sure type and location are from the same list entry are not = possible > with the YANG unique-stmt. I am not an expert on XSD but my understanding is this is exactly what = XSD would do if selector =3D current(). Lada =20 >=20 >>=20 >> The drawback is that this looks more complicated... >>=20 >=20 > It allows more arbitrary placement of the unique-stmt, which is more = complicated > and may not provide much more real utility. >=20 > IMO the new interpretation of unique-stmt can cause more problems > than it solves. Potential for garbage-in/garbage-out is very high. > Tools will not be able to analyze the intent, so only XPath experts > will get this right. >=20 >=20 >>=20 >>=20 >>=20 >> /martin >>=20 >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Mon Mar 5 12:14:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD79E11E8089 for ; Mon, 5 Mar 2012 12:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG3weDBOMGge for ; Mon, 5 Mar 2012 12:14:21 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 0710811E8088 for ; Mon, 5 Mar 2012 12:14:20 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25KEK9j012572 for ; Mon, 5 Mar 2012 15:14:20 -0500 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37530] helo=[192.168.0.9]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id DC/90-22803-B9E155F4; Mon, 05 Mar 2012 15:14:20 -0500 Message-ID: <4F551EA8.2020406@netconfcentral.org> Date: Mon, 05 Mar 2012 12:14:32 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> <4F54E585.3020507@netconfcentral.org> <220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz> In-Reply-To: <220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:14:21 -0000 On 03/05/2012 11:56 AM, Ladislav Lhotka wrote: > > On Mar 5, 2012, at 5:10 PM, Andy Bierman wrote: > >> On 03/05/2012 05:39 AM, Martin Bjorklund wrote: >> ... >>> The problem is that the text in 6020 is unclear. The text: >>> >>> "the combined values of all the leaf instances [...] MUST be unique" >>> >>> can be interpreted in different ways. >>> >>> OTOH, the WG has published two documents related to this, 6020 and >>> 6110. 6020 in itself is unclear, but if you also read 6110, the >>> interpretation is well-defined. >>> >>> So, we have two options. Either we say that with the two documents, >>> the meaning is well-defined, or we say that since 6020 is unclear, we >>> cannot publish any module that uses sublists in the unique statement. >>> >> >> I don't think it is a good idea to declare 6020 "fixed" by 6110. >> Tools conforming to 6020 should not be made instantly non-compliant >> because the spec is silent on an issue. > > Thing is, the text in 6020 is unclear and ambiguous, and apparently there are already different tools that behave differently. This should certainly be avoided. > Yes -- in future versions of the RFC you clarify ambiguous text, like we just did from NETCONF 1.0 to NETCONF 1.1. You cannot fix missing normative text with an RFC Errata when there was no clear intent by the WG for 1 implementation choice or another. >> >> A future version of YANG can declare this fixed, but not 6020. >> >>> [In any case, I will try to fix my implementation to work as defined >>> in 6110.] >>> >>> BTW, they got this right in XSD. We should have done something like: >>> >>> unique { >>> [selector;] // default is "current()" >>> field; >>> ... >>> field; >>> [error-message;] >>> [description;] >>> } >>> >>> Then we could also handle multiple keys in sublists: >>> >>> list router { >>> unique { >>> selector "interfaces/interface"; >>> // assuming type and location were used instead of name >>> field "type"; >>> field "location"; >>> } >>> } >> >> Why can't I just do: >> >> unique "interfaces/interface/type interfaces/interface/location"; >> >> The nodes in the unique tuple become completely unrelated in your new interpretation >> of unique-stmt. There is no attempt to correlate keys. Attempts to >> make sure type and location are from the same list entry are not possible >> with the YANG unique-stmt. > > I am not an expert on XSD but my understanding is this is exactly what XSD would do if selector = current(). > See my example for unique 'pair/x pair/y'. YANG does not work the way you claim. There is no requirement to pick a nested current() node in each list entry. The context node is the list node that contains the unique-stmt. (E.g., I can have "a/b/c x w/x/y/z" and they all share the same list node as the context node. Some sub-nodes may be in lists, some not.) There is no requirement for the compiler or server to correlate nested list entries and apply a nested context node while evaluating the expression. I think your XPath is wrong. YANG does not prevent partial pairs from being combined in a nodeset: pair/x: { 1, missing } pair/y: { missing, 1 } This collapses to a single pair in XPath evaluation { 1, 1 } which is wrong. > Lada > Andy From lhotka@nic.cz Mon Mar 5 12:18:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C8711E809A for ; Mon, 5 Mar 2012 12:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlaE1bZvaRyD for ; Mon, 5 Mar 2012 12:18:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DA6CA11E8099 for ; Mon, 5 Mar 2012 12:18:15 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id EC8992A2769; Mon, 5 Mar 2012 21:18:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330978695; bh=sa1JyfdI4+Q0+WX9K+wXqO+I78GFoWwlIObL9uGYEVg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NssCFZLeGQT40j82P0QOas5Uwj4BPRyh6NKNF+SDQSqrV+ZEKZRsEWmAvgJ+jI0rK r5sd7Il9e8g1yzrRlo9v3jTTAQFDH6xgygR6Yo3R9fTmCZCcAObWhoffCa+8K4xIhh 11kKTOsXx3wQGHbApwDlZOcDSRvYs4JLsG1eJgUU= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F550EA8.8050008@netconfcentral.org> Date: Mon, 5 Mar 2012 21:18:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1EAB6EDA-E3C9-4995-B141-C91610C44E1C@nic.cz> References: <4F54E585.3020507@netconfcentral.org> <20120305.185159.505003480.mbj@tail-f.com> <4F55018A.9090908@netconfcentral.org> <20120305.194411.335944913.mbj@tail-f.com> <4F550EA8.8050008@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:18:17 -0000 On Mar 5, 2012, at 8:06 PM, Andy Bierman wrote: > On 03/05/2012 10:44 AM, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> .. >>>> Actually, I think it is the other way around. Without it, you need = to >>>> write the explicit low-level XPath expression in a must statement, >>>> instead of the high-level unique statement. >>>>=20 >>>=20 >>> If only the YANG unique-stmt actually worked for node-sets if N> 1. >>> The must-stmt would be rather complex to make sure the tuple being >>> compared came from the same nested list entries. I challenge you >>> to find a use-case where it doesn't matter if pairs are incorrectly >>> formed from different list instances. >>=20 >> No need to challenge; I agree. >>=20 >>> The XPath Lada generates >>> is all very nice, but logical-AND of N unrelated node-set = comparisons is >>> not semantically useful. >>=20 >> Agreed. >>=20 >>> There is a reason the xsd:unique statement is constrained to >>> pick N fields from the same context node. Doing otherwise >>> produces garbage results. >>=20 >> Agreed. >>=20 >>> IMO, it is not really worth it to have some CLRs for unique-stmt, >>> like lists are OK for 1 node in the unique-stmt only. >>=20 >> That was also my opinion earlier, when I told you that sublists were >> not allowed. But Lada's solution is very elegant. It provides an >> unambigous interpretation of the unique statement. Quoting from his >> email: >>=20 >> - works as expected for the no-sublist case, >> - works for the use case in the routing module: list of sublists, >> one node in the tuple. >> - is well-defined for all other cases. >>=20 >> Note the last bullet. With Lada's interpretation, we wouldn't need = to >> have this debates of what the meaning of a certain unique expression >> is. >>=20 >=20 > This is a straw-man, because we could just as easily decide that RFC = 6020 > does not support nested lists and be done with it. How can you decide this without changing 6020? IMO the current text = doesn't forbid lists along the path of descendant node ids. >=20 > I am concerned that the only use-case for multiple nodes is to > compare them from the same context node, and that is not what YANG = does. > A little bullet in an RFC Errata is not going to remove that = confusion. > Being 'well-defined' to do the wrong thing is not that compelling to = me. The case of a sublist and several nodes in the tuple doesn't seem useful = but *if* somebody used it, the result is well-defined and can be = verified. Forbidding sublists entirely means eliminating an existing use = case with one node in the tuple. Do you prefer a formidable 'must' = expression in its place? Lada >=20 >>=20 >> /martin >>=20 >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Mon Mar 5 12:44:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95821F844B for ; Mon, 5 Mar 2012 12:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P60xth5REAnd for ; Mon, 5 Mar 2012 12:44:31 -0800 (PST) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 735D911E80C2 for ; Mon, 5 Mar 2012 12:44:31 -0800 (PST) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25KiTfq015385 for ; Mon, 5 Mar 2012 15:44:29 -0500 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37575] helo=[192.168.0.9]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id AC/AE-23992-CA5255F4; Mon, 05 Mar 2012 15:44:29 -0500 Message-ID: <4F5525BA.1080506@netconfcentral.org> Date: Mon, 05 Mar 2012 12:44:42 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <4F54E585.3020507@netconfcentral.org> <20120305.185159.505003480.mbj@tail-f.com> <4F55018A.9090908@netconfcentral.org> <20120305.194411.335944913.mbj@tail-f.com> <4F550EA8.8050008@netconfcentral.org> <1EAB6EDA-E3C9-4995-B141-C91610C44E1C@nic.cz> In-Reply-To: <1EAB6EDA-E3C9-4995-B141-C91610C44E1C@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:44:32 -0000 On 03/05/2012 12:18 PM, Ladislav Lhotka wrote: > > On Mar 5, 2012, at 8:06 PM, Andy Bierman wrote: > >> On 03/05/2012 10:44 AM, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> .. >>>>> Actually, I think it is the other way around. Without it, you need to >>>>> write the explicit low-level XPath expression in a must statement, >>>>> instead of the high-level unique statement. >>>>> >>>> >>>> If only the YANG unique-stmt actually worked for node-sets if N> 1. >>>> The must-stmt would be rather complex to make sure the tuple being >>>> compared came from the same nested list entries. I challenge you >>>> to find a use-case where it doesn't matter if pairs are incorrectly >>>> formed from different list instances. >>> >>> No need to challenge; I agree. >>> >>>> The XPath Lada generates >>>> is all very nice, but logical-AND of N unrelated node-set comparisons is >>>> not semantically useful. >>> >>> Agreed. >>> >>>> There is a reason the xsd:unique statement is constrained to >>>> pick N fields from the same context node. Doing otherwise >>>> produces garbage results. >>> >>> Agreed. >>> >>>> IMO, it is not really worth it to have some CLRs for unique-stmt, >>>> like lists are OK for 1 node in the unique-stmt only. >>> >>> That was also my opinion earlier, when I told you that sublists were >>> not allowed. But Lada's solution is very elegant. It provides an >>> unambigous interpretation of the unique statement. Quoting from his >>> email: >>> >>> - works as expected for the no-sublist case, >>> - works for the use case in the routing module: list of sublists, >>> one node in the tuple. >>> - is well-defined for all other cases. >>> >>> Note the last bullet. With Lada's interpretation, we wouldn't need to >>> have this debates of what the meaning of a certain unique expression >>> is. >>> >> >> This is a straw-man, because we could just as easily decide that RFC 6020 >> does not support nested lists and be done with it. > > How can you decide this without changing 6020? IMO the current text doesn't forbid lists along the path of descendant node ids. > OK -- at best that means that valid tools can implement either way. Therefore, it is a MAY implement, and standard YANG modules cannot use language features that are not required by all implementations. >> >> I am concerned that the only use-case for multiple nodes is to >> compare them from the same context node, and that is not what YANG does. >> A little bullet in an RFC Errata is not going to remove that confusion. >> Being 'well-defined' to do the wrong thing is not that compelling to me. > > The case of a sublist and several nodes in the tuple doesn't seem useful but *if* somebody used it, the result is well-defined and can be verified. Forbidding sublists entirely means eliminating an existing use case with one node in the tuple. Do you prefer a formidable 'must' expression in its place? > It is less than useful and there's nothing in YANG that says list/leaf1 and list/leaf2 come from the same instance of 'list'. Leaf1 and leaf2 do not even need to be siblings in xsd:unique. (field a, field b/c/d). In the future, unique-stmt can be deprecated and a proper unique2-stmt can replace it in YANG 1.x, like Martin proposed. Pretending that RFC 6020 supports the xsd:unique 'field' parameter is not possible. IMO, high-level user-friendly YANG statements are good, but only if they prevent the user from doing something that does not work. > Lada Andy From lhotka@nic.cz Mon Mar 5 13:05:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F72521F896F for ; Mon, 5 Mar 2012 13:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLfLo6zD0YTo for ; Mon, 5 Mar 2012 13:05:53 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87521E8028 for ; Mon, 5 Mar 2012 13:05:53 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 872752A087D; Mon, 5 Mar 2012 22:05:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330981552; bh=E5I3ixsIlgzChVTarW6zcAB1xX8Hb+zqHDkOGFoyOLI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ED8hRcfN406SrCgfyE+/nw9d8iuBmIC880OAeiVJ0Hy+BzYtEUq1V1Qw2Twhrq+qt 0vfv/nOGHo1Z383HDjgjmKA3xWvwOKqV1l4lLZYJsoHlacWegyinIYo8YcJQQlBxz2 2AWSreXcKkO2AupKFobqc4jhq+a4jniuVAu/vsyk= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F551EA8.2020406@netconfcentral.org> Date: Mon, 5 Mar 2012 22:05:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> <4F54E585.3020507@netconfcentral.org> <220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz> <4F551EA8.2020406@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:05:54 -0000 On Mar 5, 2012, at 9:14 PM, Andy Bierman wrote: > On 03/05/2012 11:56 AM, Ladislav Lhotka wrote: >>=20 >> On Mar 5, 2012, at 5:10 PM, Andy Bierman wrote: >>=20 >>> On 03/05/2012 05:39 AM, Martin Bjorklund wrote: >>> ... >>>> The problem is that the text in 6020 is unclear. The text: >>>>=20 >>>> "the combined values of all the leaf instances [...] MUST be = unique" >>>>=20 >>>> can be interpreted in different ways. >>>>=20 >>>> OTOH, the WG has published two documents related to this, 6020 and >>>> 6110. 6020 in itself is unclear, but if you also read 6110, the >>>> interpretation is well-defined. >>>>=20 >>>> So, we have two options. Either we say that with the two = documents, >>>> the meaning is well-defined, or we say that since 6020 is unclear, = we >>>> cannot publish any module that uses sublists in the unique = statement. >>>>=20 >>>=20 >>> I don't think it is a good idea to declare 6020 "fixed" by 6110. >>> Tools conforming to 6020 should not be made instantly non-compliant >>> because the spec is silent on an issue. >>=20 >> Thing is, the text in 6020 is unclear and ambiguous, and apparently = there are already different tools that behave differently. This should = certainly be avoided. >>=20 >=20 > Yes -- in future versions of the RFC you clarify ambiguous text, > like we just did from NETCONF 1.0 to NETCONF 1.1. > You cannot fix missing normative text with an RFC Errata > when there was no clear intent by the WG for 1 implementation > choice or another. IMO something like this could be accepted as an erratum: The textual definition of 'unique' turns out to be ambiguous in certain = situations. In case of doubt, the standardized mapping of 'unique' to = Schematron (RFC 6110, sec. 12.16) should be used to resolve the = ambiguity. =20 >=20 >=20 >>>=20 >>> A future version of YANG can declare this fixed, but not 6020. >>>=20 >>>> [In any case, I will try to fix my implementation to work as = defined >>>> in 6110.] >>>>=20 >>>> BTW, they got this right in XSD. We should have done something = like: >>>>=20 >>>> unique { >>>> [selector;] // default is "current()" >>>> field; >>>> ... >>>> field; >>>> [error-message;] >>>> [description;] >>>> } >>>>=20 >>>> Then we could also handle multiple keys in sublists: >>>>=20 >>>> list router { >>>> unique { >>>> selector "interfaces/interface"; >>>> // assuming type and location were used instead of name >>>> field "type"; >>>> field "location"; >>>> } >>>> } >>>=20 >>> Why can't I just do: >>>=20 >>> unique "interfaces/interface/type interfaces/interface/location"; >>>=20 >>> The nodes in the unique tuple become completely unrelated in your = new interpretation >>> of unique-stmt. There is no attempt to correlate keys. Attempts to >>> make sure type and location are from the same list entry are not = possible >>> with the YANG unique-stmt. >>=20 >> I am not an expert on XSD but my understanding is this is exactly = what XSD would do if selector =3D current(). >>=20 >=20 >=20 > See my example for unique 'pair/x pair/y'. > YANG does not work the way you claim. I can only claim how I understood the text in 6020 and how I implemented = it. > There is no requirement to pick a nested current() node in each list = entry. > The context node is the list node that contains the unique-stmt. > (E.g., I can have "a/b/c x w/x/y/z" and they all share the same list = node > as the context node. Some sub-nodes may be in lists, some not.) >=20 > There is no requirement for the compiler or server to correlate nested = list entries > and apply a nested context node while evaluating the expression. > I think your XPath is wrong. YANG does not prevent partial pairs from = being > combined in a nodeset: >=20 > pair/x: { 1, missing } > pair/y: { missing, 1 } >=20 > This collapses to a single pair in XPath evaluation { 1, 1 } which is = wrong. How can you tell? My point is: if we DEFINE 'unique' as syntactic sugar = for a 'must' statement with my XPath expression, all currently existing = use cases for 'unique' will work fine and there will be no ambiguity in = other cases, too. As far as I can tell, the only outstanding issue is to = change some tools to behave accordingly. Lada =20 >=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Mon Mar 5 14:03:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2640C21F8868 for ; Mon, 5 Mar 2012 14:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiSLcYXoBAwG for ; Mon, 5 Mar 2012 14:03:48 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id EA6A621F8864 for ; Mon, 5 Mar 2012 14:03:45 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q25M3iHn018117 for ; Mon, 5 Mar 2012 17:03:44 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37685] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E0/3E-32269-F38355F4; Mon, 05 Mar 2012 17:03:44 -0500 Message-ID: <4F55384C.3080109@netconfcentral.org> Date: Mon, 05 Mar 2012 14:03:56 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> <4F54E585.3020507@netconfcentral.org> <220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz> <4F551EA8.2020406@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:03:49 -0000 On 03/05/2012 01:05 PM, Ladislav Lhotka wrote: > > On Mar 5, 2012, at 9:14 PM, Andy Bierman wrote: > >> On 03/05/2012 11:56 AM, Ladislav Lhotka wrote: >>> >>> On Mar 5, 2012, at 5:10 PM, Andy Bierman wrote: >>> >>>> On 03/05/2012 05:39 AM, Martin Bjorklund wrote: >>>> ... >>>>> The problem is that the text in 6020 is unclear. The text: >>>>> >>>>> "the combined values of all the leaf instances [...] MUST be unique" >>>>> >>>>> can be interpreted in different ways. >>>>> >>>>> OTOH, the WG has published two documents related to this, 6020 and >>>>> 6110. 6020 in itself is unclear, but if you also read 6110, the >>>>> interpretation is well-defined. >>>>> >>>>> So, we have two options. Either we say that with the two documents, >>>>> the meaning is well-defined, or we say that since 6020 is unclear, we >>>>> cannot publish any module that uses sublists in the unique statement. >>>>> >>>> >>>> I don't think it is a good idea to declare 6020 "fixed" by 6110. >>>> Tools conforming to 6020 should not be made instantly non-compliant >>>> because the spec is silent on an issue. >>> >>> Thing is, the text in 6020 is unclear and ambiguous, and apparently there are already different tools that behave differently. This should certainly be avoided. >>> >> >> Yes -- in future versions of the RFC you clarify ambiguous text, >> like we just did from NETCONF 1.0 to NETCONF 1.1. >> You cannot fix missing normative text with an RFC Errata >> when there was no clear intent by the WG for 1 implementation >> choice or another. > > IMO something like this could be accepted as an erratum: > > The textual definition of 'unique' turns out to be ambiguous in certain situations. In case of doubt, the standardized mapping of 'unique' to Schematron (RFC 6110, sec. 12.16) should be used to resolve the ambiguity. > Then the dangers of nested incomplete pairs are completely obscured. I don't want any CLRs because that just gives tools more work to do. >> >> >>>> >>>> A future version of YANG can declare this fixed, but not 6020. >>>> >>>>> [In any case, I will try to fix my implementation to work as defined >>>>> in 6110.] >>>>> >>>>> BTW, they got this right in XSD. We should have done something like: >>>>> >>>>> unique { >>>>> [selector;] // default is "current()" >>>>> field; >>>>> ... >>>>> field; >>>>> [error-message;] >>>>> [description;] >>>>> } >>>>> >>>>> Then we could also handle multiple keys in sublists: >>>>> >>>>> list router { >>>>> unique { >>>>> selector "interfaces/interface"; >>>>> // assuming type and location were used instead of name >>>>> field "type"; >>>>> field "location"; >>>>> } >>>>> } >>>> >>>> Why can't I just do: >>>> >>>> unique "interfaces/interface/type interfaces/interface/location"; >>>> >>>> The nodes in the unique tuple become completely unrelated in your new interpretation >>>> of unique-stmt. There is no attempt to correlate keys. Attempts to >>>> make sure type and location are from the same list entry are not possible >>>> with the YANG unique-stmt. >>> >>> I am not an expert on XSD but my understanding is this is exactly what XSD would do if selector = current(). >>> Right, no attempt to correlate nested keys to select nested context nodes. k_i=current()/k_i so: must "not(preceding-sibling::router [ current()/interfaces/interface/type and current()/interfaces/interface/location ])" This picks all instances of type and all instances of location, not all { type, location } pairs like xsd:unique. ... >> pair/x: { 1, missing } >> pair/y: { missing, 1 } >> >> This collapses to a single pair in XPath evaluation { 1, 1 } which is wrong. > > How can you tell? My point is: if we DEFINE 'unique' as syntactic sugar for a 'must' statement with my XPath expression, all currently existing use cases for 'unique' will work fine and there will be no ambiguity in other cases, too. As far as I can tell, the only outstanding issue is to change some tools to behave accordingly. > If my intent was to only check complete pairs, it is broken. You are saying users should know that is not what they get, so too bad if they do that. YANG Doctors will reject their module when they try to publish an RFC. OK, OK, I'll change yuma. It probably already implements unique the way you define in RFC 6110. > Lada Andy From Jonathan.Hansford@generaldynamics.uk.com Tue Mar 6 02:00:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D69021F87D6 for ; Tue, 6 Mar 2012 02:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=-1.890, BAYES_40=-0.185, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SD74jRJ1QvL for ; Tue, 6 Mar 2012 02:00:49 -0800 (PST) Received: from mail91.messagelabs.com (mail91.messagelabs.com [194.106.220.35]) by ietfa.amsl.com (Postfix) with SMTP id C0E5821F86E8 for ; Tue, 6 Mar 2012 02:00:47 -0800 (PST) X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-15.tower-91.messagelabs.com!1331028046!47870205!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8041 invoked from network); 6 Mar 2012 10:00:46 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-15.tower-91.messagelabs.com with SMTP; 6 Mar 2012 10:00:46 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 06 Mar 2012 10:00:48 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 10:00:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 10:00:50 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E6505462067F4733@GDUKADH850.uk1.r-org.net> In-Reply-To: <4F55384C.3080109@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 Thread-Index: Acz7gALSB8osuoRsTNWdR4DGYYpQpg== References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net><4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com><4F54E585.3020507@netconfcentral.org><220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz><4F551EA8.2020406@netconfcentral.org> <4F55384C.3080109@netconfcentral.org> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 06 Mar 2012 10:00:46.0148 (UTC) FILETIME=[0002F040:01CCFB80] Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:00:50 -0000 Just a quick note from someone who is still getting to grips with YANG. RFC6020 section 4.1 states that "YANG provides clear and concise descriptions of the nodes, as well as the interaction between those nodes." The (from my perspective, esoteric) discussion about the current unique statement is neither a clear nor a concise description of the interaction between nodes. For those who have been immersed in YANG from its conception, this discussion may have some (intellectual?) merits. But if there will be few instances where such a use of unique would be needed, and if a must statement using an XPath can unambiguously if more verbosely support those instances (which I think is what has been stated), then it feels to me that an erratum declaring that 6020's unique statement does not support nested lists would be the sensible way to go. It may not even cross the mind of the average user that unique nested lists could exist. Further, since valid content MUST abide by constraints, there is again a risk that your average NETCONF/YANG user could generate invalid configuration data against a unique nested list and not have a clue what was wrong or how to correct it. Jonathan Hansford=20 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From lhotka@cesnet.cz Tue Mar 6 05:09:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D584A21F890B for ; Tue, 6 Mar 2012 05:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U042BC6p2xk for ; Tue, 6 Mar 2012 05:09:11 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 02DF421F88FB for ; Tue, 6 Mar 2012 05:09:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B9B56540755; Tue, 6 Mar 2012 14:09:07 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMqxLJ7lTKpQ; Tue, 6 Mar 2012 14:08:58 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9A14E540259; Tue, 6 Mar 2012 14:08:58 +0100 (CET) From: Ladislav Lhotka To: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462067F4733@GDUKADH850.uk1.r-org.net> References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net><4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com><4F54E585.3020507@netconfcentral.org><220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz><4F551EA8.2020406@netconfcentral.org> <4F55384C.3080109@netconfcentral.org> <83C941F7F59F3F42AC017AD1E6505462067F4733@GDUKADH850.uk1.r-org.net> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Date: Tue, 06 Mar 2012 14:08:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:09:12 -0000 On Tue, 6 Mar 2012 10:00:50 -0000, wrote: > Just a quick note from someone who is still getting to grips with YANG. > RFC6020 section 4.1 states that "YANG provides clear and concise > descriptions of the nodes, as well as the interaction between those > nodes." This is exactly why a concise 'unique' is preferable to an unwieldy 'must'. > > The (from my perspective, esoteric) discussion about the current unique > statement is neither a clear nor a concise description of the > interaction between nodes. For those who have been immersed in YANG from > its conception, this discussion may have some (intellectual?) merits. > But if there will be few instances where such a use of unique would be IMO, this assumption is not necessarily true. The use case is that there is a set of objects that have to be unique and these objects are divided into subsets at two or more levels. This could be quite common. > needed, and if a must statement using an XPath can unambiguously if more > verbosely support those instances (which I think is what has been > stated), then it feels to me that an erratum declaring that 6020's > unique statement does not support nested lists would be the sensible way > to go. It may not even cross the mind of the average user that unique > nested lists could exist. An average user needn't bother at all, but it has already crossed the mind of at least two YANG module developers. > > Further, since valid content MUST abide by constraints, there is again a > risk that your average NETCONF/YANG user could generate invalid > configuration data against a unique nested list and not have a clue what > was wrong or how to correct it. Validating tools should give such a clue, and descriptions should help, too. At any rate, I don't see any difference between 'unique' and 'must' here. Lada > > Jonathan Hansford > > > > This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Tue Mar 6 05:57:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79E421F8878 for ; Tue, 6 Mar 2012 05:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MANGLED_LIMITD=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc4Ml1CcwCTF for ; Tue, 6 Mar 2012 05:57:30 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1021F8871 for ; Tue, 6 Mar 2012 05:57:28 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT1YXyE6vtHKIzNPOXNiS9FrA/ERPIedY@postini.com; Tue, 06 Mar 2012 05:57:30 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 05:57:15 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q26DvE167464; Tue, 6 Mar 2012 05:57:14 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q26DQtws051493; Tue, 6 Mar 2012 13:26:56 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201203061326.q26DQtws051493@idle.juniper.net> To: In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462067F4733@GDUKADH850.uk1.r-org.net> Date: Tue, 6 Mar 2012 08:26:55 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:57:31 -0000 This sounds like a reasonable solution, and goes along with the "make easy things easy and hard things possible" mantra. Thanks, Phil Jonathan.Hansford@generaldynamics.uk.com writes: >Just a quick note from someone who is still getting to grips with YANG. >RFC6020 section 4.1 states that "YANG provides clear and concise >descriptions of the nodes, as well as the interaction between those >nodes." > >The (from my perspective, esoteric) discussion about the current unique >statement is neither a clear nor a concise description of the >interaction between nodes. For those who have been immersed in YANG from >its conception, this discussion may have some (intellectual?) merits. >But if there will be few instances where such a use of unique would be >needed, and if a must statement using an XPath can unambiguously if more >verbosely support those instances (which I think is what has been >stated), then it feels to me that an erratum declaring that 6020's >unique statement does not support nested lists would be the sensible way >to go. It may not even cross the mind of the average user that unique >nested lists could exist. > >Further, since valid content MUST abide by constraints, there is again a >risk that your average NETCONF/YANG user could generate invalid >configuration data against a unique nested list and not have a clue what >was wrong or how to correct it. > >Jonathan Hansford > > > >This email and any files attached are intended for the addressee and may contain informa >tion of a confidential nature. If you are not the intended recipient, be aware that this > email was sent to you in error and you should not disclose, distribute, print, copy or >make other use of this email or its attachments. Such actions, in fact, may be unlawful. > In compliance with the various Regulations and Acts, General Dynamics United Kingdom Li >mited reserves the right to monitor (and examine for viruses) all emails and email attac >hments, both inbound and outbound. Email communications and their attachments may not be > secure or error- or virus-free and the company does not accept liability or responsibil >ity for such matters or the consequences thereof. General Dynamics United Kingdom Limite >d, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wal >es No: 1911653. >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Tue Mar 6 06:06:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F24D21F8908 for ; Tue, 6 Mar 2012 06:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, MANGLED_LIMITD=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CL5vzM3NSNi for ; Tue, 6 Mar 2012 06:06:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 78B8821F8732 for ; Tue, 6 Mar 2012 06:06:54 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 702CB2A0905; Tue, 6 Mar 2012 15:06:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331042813; bh=v1Vty2SL/z+ozdEgEkBnqlBWw+YxBPLDLsRsymBI/og=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=miWjfDopT8OavOCFdRxk252/WKztHUIhecbozPbq5XtKoFTCs/ev5n0xt/LRuBMd1 Lpuq2uNCNq1p0TVIa+LwW6na3/38DUn3vEVFwOhPwxXGuOdGsIOLpdkweBx74NAHXv VXFmyYjyh3MSO/AEh8+M0EhxTkiIifjYDgb8cFZE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <201203061326.q26DQtws051493@idle.juniper.net> Date: Tue, 6 Mar 2012 15:06:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C2BFD79-0C66-4D29-95FA-CDAB8B2F5593@nic.cz> References: <201203061326.q26DQtws051493@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:06:55 -0000 On Mar 6, 2012, at 2:26 PM, Phil Shafer wrote: > This sounds like a reasonable solution, and goes along with > the "make easy things easy and hard things possible" mantra. Why is this better than "make easy things easy, moderately difficult = things easy and hard things possible"? Lada >=20 > Thanks, > Phil >=20 >=20 >=20 > Jonathan.Hansford@generaldynamics.uk.com writes: >> Just a quick note from someone who is still getting to grips with = YANG. >> RFC6020 section 4.1 states that "YANG provides clear and concise >> descriptions of the nodes, as well as the interaction between those >> nodes." >>=20 >> The (from my perspective, esoteric) discussion about the current = unique >> statement is neither a clear nor a concise description of the >> interaction between nodes. For those who have been immersed in YANG = from >> its conception, this discussion may have some (intellectual?) merits. >> But if there will be few instances where such a use of unique would = be >> needed, and if a must statement using an XPath can unambiguously if = more >> verbosely support those instances (which I think is what has been >> stated), then it feels to me that an erratum declaring that 6020's >> unique statement does not support nested lists would be the sensible = way >> to go. It may not even cross the mind of the average user that unique >> nested lists could exist. >>=20 >> Further, since valid content MUST abide by constraints, there is = again a >> risk that your average NETCONF/YANG user could generate invalid >> configuration data against a unique nested list and not have a clue = what >> was wrong or how to correct it. >>=20 >> Jonathan Hansford=20 >>=20 >>=20 >>=20 >> This email and any files attached are intended for the addressee and = may contain informa >> tion of a confidential nature. If you are not the intended recipient, = be aware that this >> email was sent to you in error and you should not disclose, = distribute, print, copy or=20 >> make other use of this email or its attachments. Such actions, in = fact, may be unlawful. >> In compliance with the various Regulations and Acts, General Dynamics = United Kingdom Li >> mited reserves the right to monitor (and examine for viruses) all = emails and email attac >> hments, both inbound and outbound. Email communications and their = attachments may not be >> secure or error- or virus-free and the company does not accept = liability or responsibil >> ity for such matters or the consequences thereof. General Dynamics = United Kingdom Limite >> d, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered = in England and Wal >> es No: 1911653.=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Tue Mar 6 10:13:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA42821F87ED for ; Tue, 6 Mar 2012 10:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SsTqCIwfl3W for ; Tue, 6 Mar 2012 10:13:58 -0800 (PST) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id B49F821F87F3 for ; Tue, 6 Mar 2012 10:13:56 -0800 (PST) Received: from host86-163-139-217.range86-163.btcentralplus.com (HELO pc6) ([86.163.139.217]) by c2bthomr13.btconnect.com with SMTP id GOJ75744; Tue, 06 Mar 2012 18:13:48 +0000 (GMT) Message-ID: <006501ccfbbc$68ca17c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ladislav Lhotka" , "Andy Bierman" References: <01e101ccf950$f9b09160$4001a8c0@gateway.2wire.net> <4F524D41.9020700@netconfcentral.org> <20120305.143906.198953730820615646.mbj@tail-f.com> <4F54E585.3020507@netconfcentral.org> <220938DC-03B0-440F-AD6C-4BC3C648DFE1@nic.cz> <4F551EA8.2020406@netconfcentral.org> Date: Tue, 6 Mar 2012 18:13:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F5653DB.0058, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2012.3.6.173316:17:8.317, ip=86.163.139.217, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __STOCK_PHRASE_24, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4F5653DD.003E,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:13:59 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Andy Bierman" Cc: "Martin Bjorklund" ; ; Sent: Monday, March 05, 2012 10:05 PM On Mar 5, 2012, at 9:14 PM, Andy Bierman wrote: > On 03/05/2012 11:56 AM, Ladislav Lhotka wrote: >> >> On Mar 5, 2012, at 5:10 PM, Andy Bierman wrote: >> >>> On 03/05/2012 05:39 AM, Martin Bjorklund wrote: >>> ... >>>> The problem is that the text in 6020 is unclear. The text: >>>> >>>> "the combined values of all the leaf instances [...] MUST be unique" >>>> >>>> can be interpreted in different ways. >>>> >>>> OTOH, the WG has published two documents related to this, 6020 and >>>> 6110. 6020 in itself is unclear, but if you also read 6110, the >>>> interpretation is well-defined. >>>> >>>> So, we have two options. Either we say that with the two documents, >>>> the meaning is well-defined, or we say that since 6020 is unclear, we >>>> cannot publish any module that uses sublists in the unique statement. >>>> >>> >>> I don't think it is a good idea to declare 6020 "fixed" by 6110. >>> Tools conforming to 6020 should not be made instantly non-compliant >>> because the spec is silent on an issue. >> >> Thing is, the text in 6020 is unclear and ambiguous, and apparently there are already different tools that behave differently. This should certainly be avoided. >> > > Yes -- in future versions of the RFC you clarify ambiguous text, > like we just did from NETCONF 1.0 to NETCONF 1.1. > You cannot fix missing normative text with an RFC Errata > when there was no clear intent by the WG for 1 implementation > choice or another. IMO something like this could be accepted as an erratum: The textual definition of 'unique' turns out to be ambiguous in certain situations. In case of doubt, the standardized mapping of 'unique' to Schematron (RFC 6110, sec. 12.16) should be used to resolve the ambiguity. Whether or not this would be accepted as an erratum, the problem is that so many people do not know to look for errata, perhaps expecting there to be a later RFC instead. A route that is more likely to be noticed would be to publish an RFC that updates that section; being listed in the rfc-index as 'updates' is far more likely to be noticed and acted upon. The challenge then would be to avoid the pork barrel, "while we are at it we could also just ..... (Please, no)". Tom Petch >>> A future version of YANG can declare this fixed, but not 6020. >>> >>>> [In any case, I will try to fix my implementation to work as defined >>>> in 6110.] >>>> >>>> BTW, they got this right in XSD. We should have done something like: >>>> >>>> unique { >>>> [selector;] // default is "current()" >>>> field; >>>> ... >>>> field; >>>> [error-message;] >>>> [description;] >>>> } >>>> >>>> Then we could also handle multiple keys in sublists: >>>> >>>> list router { >>>> unique { >>>> selector "interfaces/interface"; >>>> // assuming type and location were used instead of name >>>> field "type"; >>>> field "location"; >>>> } >>>> } >>> >>> Why can't I just do: >>> >>> unique "interfaces/interface/type interfaces/interface/location"; >>> >>> The nodes in the unique tuple become completely unrelated in your new interpretation >>> of unique-stmt. There is no attempt to correlate keys. Attempts to >>> make sure type and location are from the same list entry are not possible >>> with the YANG unique-stmt. >> >> I am not an expert on XSD but my understanding is this is exactly what XSD would do if selector = current(). >> > > > See my example for unique 'pair/x pair/y'. > YANG does not work the way you claim. I can only claim how I understood the text in 6020 and how I implemented it. > There is no requirement to pick a nested current() node in each list entry. > The context node is the list node that contains the unique-stmt. > (E.g., I can have "a/b/c x w/x/y/z" and they all share the same list node > as the context node. Some sub-nodes may be in lists, some not.) > > There is no requirement for the compiler or server to correlate nested list entries > and apply a nested context node while evaluating the expression. > I think your XPath is wrong. YANG does not prevent partial pairs from being > combined in a nodeset: > > pair/x: { 1, missing } > pair/y: { missing, 1 } > > This collapses to a single pair in XPath evaluation { 1, 1 } which is wrong. How can you tell? My point is: if we DEFINE 'unique' as syntactic sugar for a 'must' statement with my XPath expression, all currently existing use cases for 'unique' will work fine and there will be no ambiguity in other cases, too. As far as I can tell, the only outstanding issue is to change some tools to behave accordingly. Lada > >> Lada >> > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Tue Mar 6 10:52:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B3D21E8096 for ; Tue, 6 Mar 2012 10:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOEq187gGT1E for ; Tue, 6 Mar 2012 10:52:24 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 92B1B21E805E for ; Tue, 6 Mar 2012 10:52:19 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT1Zc4xYdXStAyasSdcT0a+Z0jg/FKeHU@postini.com; Tue, 06 Mar 2012 10:52:24 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 10:52:07 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q26Iq5163391; Tue, 6 Mar 2012 10:52:05 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q26ILklW053713; Tue, 6 Mar 2012 18:21:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201203061821.q26ILklW053713@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <5C2BFD79-0C66-4D29-95FA-CDAB8B2F5593@nic.cz> Date: Tue, 6 Mar 2012 13:21:46 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:52:25 -0000 Ladislav Lhotka writes: >> This sounds like a reasonable solution, and goes along with >> the "make easy things easy and hard things possible" mantra. >Why is this better than "make easy things easy, moderately difficult = >things easy and hard things possible"? The concern is that you're making rare cases easier at the cost of our "clear and concise descriptions". This is what Jonathan was expressing, and I concur. Thanks, Phil From lhotka@cesnet.cz Tue Mar 6 12:22:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4852721F86E5 for ; Tue, 6 Mar 2012 12:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eoFQvApTeoj for ; Tue, 6 Mar 2012 12:22:21 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id ABECE21F86E4 for ; Tue, 6 Mar 2012 12:22:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C0731540755; Tue, 6 Mar 2012 21:22:18 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOnvG4LTpzJO; Tue, 6 Mar 2012 21:22:12 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BB9E6540259; Tue, 6 Mar 2012 21:22:12 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201203061821.q26ILklW053713@idle.juniper.net> References: <201203061821.q26ILklW053713@idle.juniper.net> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Date: Tue, 06 Mar 2012 21:22:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:22:22 -0000 On Tue, 6 Mar 2012 13:21:46 -0500, Phil Shafer wrote: > Ladislav Lhotka writes: > >> This sounds like a reasonable solution, and goes along with > >> the "make easy things easy and hard things possible" mantra. > >Why is this better than "make easy things easy, moderately difficult = > >things easy and hard things possible"? > > The concern is that you're making rare cases easier at the > cost of our "clear and concise descriptions". This is what > Jonathan was expressing, and I concur. I don't get it. The sentence Jonathan cited from 6020 is about clear and concise description of nodes and this is exactly what 'unique' is in comparison to a long and incomprehensible 'must' expression. And the simple case doesn't change at all. I understand Andy's concern that somebody might try to use 'unique' with sublists and multiple nodes in the tuple, and expect an outcome different from what the XPath expression in 6110 does. We haven't seen a use case for this yet but even if one is found - I believe a data modeller doing such nontrivial things should have enough expertise to be able to figure out what that XPath expression means because, in any case, his only option will be to write his own (probably even more complicated) 'must' statement. Lada > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Tue Mar 6 15:19:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D760721E8010 for ; Tue, 6 Mar 2012 15:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeER2YPai5oc for ; Tue, 6 Mar 2012 15:19:59 -0800 (PST) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id A16EC21F85AA for ; Tue, 6 Mar 2012 15:19:52 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q26NJpKK015247 for ; Tue, 6 Mar 2012 18:19:52 -0500 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:41819] helo=[192.168.0.9]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 03/54-09323-69B965F4; Tue, 06 Mar 2012 18:19:51 -0500 Message-ID: <4F569BA4.80102@netconfcentral.org> Date: Tue, 06 Mar 2012 15:20:04 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org References: <201203061821.q26ILklW053713@idle.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:20:00 -0000 On 03/06/2012 12:22 PM, Ladislav Lhotka wrote: > On Tue, 6 Mar 2012 13:21:46 -0500, Phil Shafer wrote: >> Ladislav Lhotka writes: >>>> This sounds like a reasonable solution, and goes along with >>>> the "make easy things easy and hard things possible" mantra. >>> Why is this better than "make easy things easy, moderately difficult = >>> things easy and hard things possible"? >> >> The concern is that you're making rare cases easier at the >> cost of our "clear and concise descriptions". This is what >> Jonathan was expressing, and I concur. > > I don't get it. The sentence Jonathan cited from 6020 is about clear and concise description of nodes and this is exactly what 'unique' is in comparison to a long and incomprehensible 'must' expression. And the simple case doesn't change at all. > > I understand Andy's concern that somebody might try to use 'unique' with sublists and multiple nodes in the tuple, and expect an outcome different from what the XPath expression in 6110 does. > We haven't seen a use case for this yet but even if one is found - I believe a data modeller doing such nontrivial things should have enough expertise to be able to figure out what that XPath expression means because, in any case, his only option will be to write his own (probably even more complicated) 'must' statement. > I have a new concern -- the error handling -- it is not always possible to return the as required for lists. 13.1. Error Message for Data That Violates a unique Statement If a NETCONF operation would result in configuration data where a unique constraint is invalidated, the following error is returned: error-tag: operation-failed error-app-tag: data-not-unique error-info: : Contains an instance identifier that points to a leaf that invalidates the unique constraint. This element is present once for each non-unique leaf. The element is in the YANG namespace ("urn:ietf:params:xml:ns:yang:1"). It is very difficult to dig into the XPath internals and figure out the exact instance(s) within 2 node-sets that caused the comparison to be equal to 'true'. XPath says true on the first hit, so a parser will not look for more matches, or indicate which exact node(s) matched in the unique-test. So the default (pick first node in the node-set) does not work for lists, like it does for container or leaf. The value returned might be wrong. > Lada > Andy From Jonathan.Hansford@generaldynamics.uk.com Wed Mar 7 02:22:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DBF21F87BE for ; Wed, 7 Mar 2012 02:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41VZMtJXk-WT for ; Wed, 7 Mar 2012 02:22:34 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 57CB421F87A5 for ; Wed, 7 Mar 2012 02:22:33 -0800 (PST) Received: from [85.158.136.3:22880] by server-3.bemta-5.messagelabs.com id 07/B8-25237-8E6375F4; Wed, 07 Mar 2012 10:22:32 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-8.tower-123.messagelabs.com!1331115752!21949314!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22058 invoked from network); 7 Mar 2012 10:22:32 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-8.tower-123.messagelabs.com with SMTP; 7 Mar 2012 10:22:32 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 07 Mar 2012 10:22:34 +0000 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 10:22:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 10:22:35 -0000 Message-ID: <83C941F7F59F3F42AC017AD1E6505462067F49DE@GDUKADH850.uk1.r-org.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 Thread-Index: Acz71tTAbraMp30IQpur9QC7i9w89AAcrGiA References: <201203061821.q26ILklW053713@idle.juniper.net> From: To: , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 07 Mar 2012 10:22:36.0625 (UTC) FILETIME=[37879C10:01CCFC4C] Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:22:35 -0000 Lada, I intended to focus more on the "clear and concise descriptions of the =2E.. interaction between those nodes". Though I concur that unique is concise, I am not convinced it is clear. If it were, we wouldn't have two incompatible implementations.=20 Ambiguity is the enemy of system management and system integration; we cannot afford to have situations where client and server implementations are incompatible. Ultimately what is needed is an unambiguous definition of what unique means for nested lists. Since I have yet to see a reason why I would want to use unique for nested lists, I am ambivalent on whether it should be supported. I leave that decision to those who can see its utility and those who can see its current weaknesses.=20 Jonathan Hansford > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: 06 March 2012 20:22 > To: Phil Shafer > Cc: Jonathan Hansford; netmod@ietf.org > Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 >=20 > On Tue, 6 Mar 2012 13:21:46 -0500, Phil Shafer wrote: > > Ladislav Lhotka writes: > > >> This sounds like a reasonable solution, and goes along with > > >> the "make easy things easy and hard things possible" mantra. > > >Why is this better than "make easy things easy, moderately difficult =3D > > >things easy and hard things possible"? > > > > The concern is that you're making rare cases easier at the > > cost of our "clear and concise descriptions". This is what > > Jonathan was expressing, and I concur. >=20 > I don't get it. The sentence Jonathan cited from 6020 is about clear and > concise description of nodes and this is exactly what 'unique' is in > comparison to a long and incomprehensible 'must' expression. And the > simple case doesn't change at all. >=20 > I understand Andy's concern that somebody might try to use 'unique' with > sublists and multiple nodes in the tuple, and expect an outcome different > from what the XPath expression in 6110 does. > We haven't seen a use case for this yet but even if one is found - I > believe a data modeller doing such nontrivial things should have enough > expertise to be able to figure out what that XPath expression means > because, in any case, his only option will be to write his own (probably > even more complicated) 'must' statement. >=20 > Lada >=20 > > > > Thanks, > > Phil >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From lhotka@cesnet.cz Wed Mar 7 10:18:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C216521F86CA for ; Wed, 7 Mar 2012 10:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EyE33HLrSY6 for ; Wed, 7 Mar 2012 10:18:50 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E123621F86CE for ; Wed, 7 Mar 2012 10:18:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D4D4F540165; Wed, 7 Mar 2012 19:18:47 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14-jrAly3YVd; Wed, 7 Mar 2012 19:18:39 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 681985400F3; Wed, 7 Mar 2012 19:18:39 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org In-Reply-To: <4F569BA4.80102@netconfcentral.org> References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Andy Bierman , Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Date: Wed, 07 Mar 2012 19:18:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:18:50 -0000 On Tue, 06 Mar 2012 15:20:04 -0800, Andy Bierman wrote: > On 03/06/2012 12:22 PM, Ladislav Lhotka wrote: > > On Tue, 6 Mar 2012 13:21:46 -0500, Phil Shafer wrote: > >> Ladislav Lhotka writes: > >>>> This sounds like a reasonable solution, and goes along with > >>>> the "make easy things easy and hard things possible" mantra. > >>> Why is this better than "make easy things easy, moderately difficult = > >>> things easy and hard things possible"? > >> > >> The concern is that you're making rare cases easier at the > >> cost of our "clear and concise descriptions". This is what > >> Jonathan was expressing, and I concur. > > > > I don't get it. The sentence Jonathan cited from 6020 is about clear and concise description of nodes and this is exactly what 'unique' is in comparison to a long and incomprehensible 'must' expression. And the simple case doesn't change at all. > > > > I understand Andy's concern that somebody might try to use 'unique' with sublists and multiple nodes in the tuple, and expect an outcome different from what the XPath expression in 6110 does. > > We haven't seen a use case for this yet but even if one is found - I believe a data modeller doing such nontrivial things should have enough expertise to be able to figure out what that XPath expression means because, in any case, his only option will be to write his own (probably even more complicated) 'must' statement. > > > > > I have a new concern -- the error handling -- it is not always possible > to return the as required for lists. > > > 13.1. Error Message for Data That Violates a unique Statement > > If a NETCONF operation would result in configuration data where a > unique constraint is invalidated, the following error is returned: > > error-tag: operation-failed > error-app-tag: data-not-unique > error-info: : Contains an instance identifier that > points to a leaf that invalidates the unique > constraint. This element is present once for each > non-unique leaf. > > The element is in the YANG > namespace ("urn:ietf:params:xml:ns:yang:1"). > > It is very difficult to dig into the XPath internals and figure > out the exact instance(s) within 2 node-sets that caused the > comparison to be equal to 'true'. XPath says true on the first > hit, so a parser will not look for more matches, or indicate which > exact node(s) matched in the unique-test. I think it is actually quite easy, you first have to pinpoint the two entries of the top level list for which the uniqueness constraint is violated, and then search again just inside these two entries. I tested it using XSLT a it seems to work. (Another interesting XSLT challenge would be to construct the instance identifiers.) Anyway, it is not necessary to use XPath for this. Lada > > So the default (pick first node in the node-set) does not work > for lists, like it does for container or leaf. The > value returned might be wrong. > > > > > Lada > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Mar 7 10:30:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3564921E80B6 for ; Wed, 7 Mar 2012 10:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBZwTpaDco0E for ; Wed, 7 Mar 2012 10:30:12 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A833321E8017 for ; Wed, 7 Mar 2012 10:30:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9E66D540165; Wed, 7 Mar 2012 19:30:09 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdlmJDoKJta5; Wed, 7 Mar 2012 19:30:03 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0FE345400F3; Wed, 7 Mar 2012 19:30:03 +0100 (CET) From: Ladislav Lhotka To: Jonathan.Hansford@generaldynamics.uk.com, phil@juniper.net In-Reply-To: <83C941F7F59F3F42AC017AD1E6505462067F49DE@GDUKADH850.uk1.r-org.net> References: <201203061821.q26ILklW053713@idle.juniper.net> <83C941F7F59F3F42AC017AD1E6505462067F49DE@GDUKADH850.uk1.r-org.net> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, phil@juniper.net, netmod@ietf.org Date: Wed, 07 Mar 2012 19:30:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:30:13 -0000 On Wed, 7 Mar 2012 10:22:35 -0000, wrote: > Lada, > > I intended to focus more on the "clear and concise descriptions of the > ... interaction between those nodes". Though I concur that unique is > concise, I am not convinced it is clear. If it were, we wouldn't have > two incompatible implementations. This was caused by the ambiguity of the existing 6020 text. I am sure we can find an unambiguous formulation for both the case with sublists and without them. > > Ambiguity is the enemy of system management and system integration; we > cannot afford to have situations where client and server implementations > are incompatible. Ultimately what is needed is an unambiguous definition > of what unique means for nested lists. > > Since I have yet to see a reason why I would want to use unique for > nested lists, I am ambivalent on whether it should be supported. I leave One use case is in the routing-cfg draft, this is where this long thread started. Lada > that decision to those who can see its utility and those who can see its > current weaknesses. > > Jonathan Hansford > > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: 06 March 2012 20:22 > > To: Phil Shafer > > Cc: Jonathan Hansford; netmod@ietf.org > > Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 > > > > On Tue, 6 Mar 2012 13:21:46 -0500, Phil Shafer > wrote: > > > Ladislav Lhotka writes: > > > >> This sounds like a reasonable solution, and goes along with > > > >> the "make easy things easy and hard things possible" mantra. > > > >Why is this better than "make easy things easy, moderately > difficult = > > > >things easy and hard things possible"? > > > > > > The concern is that you're making rare cases easier at the > > > cost of our "clear and concise descriptions". This is what > > > Jonathan was expressing, and I concur. > > > > I don't get it. The sentence Jonathan cited from 6020 is about clear > and > > concise description of nodes and this is exactly what 'unique' is in > > comparison to a long and incomprehensible 'must' expression. And the > > simple case doesn't change at all. > > > > I understand Andy's concern that somebody might try to use 'unique' > with > > sublists and multiple nodes in the tuple, and expect an outcome > different > > from what the XPath expression in 6110 does. > > We haven't seen a use case for this yet but even if one is found - I > > believe a data modeller doing such nontrivial things should have > enough > > expertise to be able to figure out what that XPath expression means > > because, in any case, his only option will be to write his own > (probably > > even more complicated) 'must' statement. > > > > Lada > > > > > > > > Thanks, > > > Phil > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Wed Mar 7 22:46:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8833421F864C for ; Wed, 7 Mar 2012 22:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wf89cV88+Cd for ; Wed, 7 Mar 2012 22:46:14 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6919821F864B for ; Wed, 7 Mar 2012 22:46:14 -0800 (PST) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q286kCVI030489 for ; Thu, 8 Mar 2012 01:46:13 -0500 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59084] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5A/2E-14799-4B5585F4; Thu, 08 Mar 2012 01:46:12 -0500 Message-ID: <4F5855B3.5000902@netconfcentral.org> Date: Wed, 07 Mar 2012 22:46:11 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:46:15 -0000 On 03/07/2012 10:18 AM, Ladislav Lhotka wrote: > On Tue, 06 Mar 2012 15:20:04 -0800, Andy Bierman wrote: >> On 03/06/2012 12:22 PM, Ladislav Lhotka wrote: >>> On Tue, 6 Mar 2012 13:21:46 -0500, Phil Shafer wrote: >>>> Ladislav Lhotka writes: >>>>>> This sounds like a reasonable solution, and goes along with >>>>>> the "make easy things easy and hard things possible" mantra. >>>>> Why is this better than "make easy things easy, moderately difficult = >>>>> things easy and hard things possible"? >>>> >>>> The concern is that you're making rare cases easier at the >>>> cost of our "clear and concise descriptions". This is what >>>> Jonathan was expressing, and I concur. >>> >>> I don't get it. The sentence Jonathan cited from 6020 is about clear and concise description of nodes and this is exactly what 'unique' is in comparison to a long and incomprehensible 'must' expression. And the simple case doesn't change at all. >>> >>> I understand Andy's concern that somebody might try to use 'unique' with sublists and multiple nodes in the tuple, and expect an outcome different from what the XPath expression in 6110 does. >>> We haven't seen a use case for this yet but even if one is found - I believe a data modeller doing such nontrivial things should have enough expertise to be able to figure out what that XPath expression means because, in any case, his only option will be to write his own (probably even more complicated) 'must' statement. >>> >> >> >> I have a new concern -- the error handling -- it is not always possible >> to return the as required for lists. >> >> >> 13.1. Error Message for Data That Violates a unique Statement >> >> If a NETCONF operation would result in configuration data where a >> unique constraint is invalidated, the following error is returned: >> >> error-tag: operation-failed >> error-app-tag: data-not-unique >> error-info:: Contains an instance identifier that >> points to a leaf that invalidates the unique >> constraint. This element is present once for each >> non-unique leaf. >> >> The element is in the YANG >> namespace ("urn:ietf:params:xml:ns:yang:1"). >> >> It is very difficult to dig into the XPath internals and figure >> out the exact instance(s) within 2 node-sets that caused the >> comparison to be equal to 'true'. XPath says true on the first >> hit, so a parser will not look for more matches, or indicate which >> exact node(s) matched in the unique-test. > > I think it is actually quite easy, you first have to pinpoint the two entries of the top level list for which the uniqueness constraint is violated, and then search again just inside these two entries. I tested it using XSLT a it seems to work. (Another interesting XSLT challenge would be to construct the instance identifiers.) > I don't and I don't see any value in implementing this error-info element. Knowing the list entry (with the unique-stmt) that failed is good enough. I also think this 'clarification' goes way beyond the bounds of any RFC Errata I've ever seen, and I strongly object to that publication mechanism. RFC Errata is for things like the missing YANG ABNF comment that says deviation sub-statements can appear in any order. That was always the intent of the WG. That is clearly indicated in other parts of the draft and nobody disagreed that the WG intent was to allow sub-statements in any order. In this case, new uses for the unique-stmt are being invented that the NETMOD WG never once discussed. I know (cuz I was there) that the authors intended unique-stmt to mean 1 leaf instance per unique node. Unfortunately the language we thought was precise is ambiguous when nested lists are considered -- something the NETMOD WG never did consider. > Anyway, it is not necessary to use XPath for this. > > Lada > Andy >> >> So the default (pick first node in the node-set) does not work >> for lists, like it does for container or leaf. The >> value returned might be wrong. >> >> >> >>> Lada >>> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Wed Mar 7 22:58:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8221E8024 for ; Wed, 7 Mar 2012 22:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw5l4o8sxMUl for ; Wed, 7 Mar 2012 22:58:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2903E21E8017 for ; Wed, 7 Mar 2012 22:58:39 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id CCC6F2A2D51; Thu, 8 Mar 2012 07:58:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331189918; bh=JZpkL+xXOmpWvd8B8r67o5OHtIs2yaUnuuLI47H/Mpw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eeh5QBGqu5pciFFjqZt00mPGz3Y1Bnx2LrgJ/lXm9rYiIIBrjU0H30iyOHJ0KXIwa y5RssUkJfM3gOl8rX6CKYng/OL/KjRm/oSLT9LGRPFf6AR2zuXvs6hy0DhHQgWy9P9 UgmysIKdBMJ1E7dzhUXKKmHxhtNKyJis2LJZV2iE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F5855B3.5000902@netconfcentral.org> Date: Thu, 8 Mar 2012 07:58:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:58:41 -0000 On Mar 8, 2012, at 7:46 AM, Andy Bierman wrote: > I don't and I don't see any value in implementing this error-info = element. > Knowing the list entry (with the unique-stmt) that failed is good = enough. I agree. Schematron gives an error message of this sort: --- Validity error at "/nc:config/t:foo": Violated uniqueness for "t:a/t:b t:c" This is IMO quite enough for locating the problem. >=20 >=20 > I also think this 'clarification' goes way beyond the bounds of any > RFC Errata I've ever seen, and I strongly object to that publication = mechanism. > RFC Errata is for things like the missing YANG ABNF comment that says = deviation > sub-statements can appear in any order. That was always the intent of = the WG. > That is clearly indicated in other parts of the draft and nobody = disagreed > that the WG intent was to allow sub-statements in any order. >=20 > In this case, new uses for the unique-stmt are being invented that the = NETMOD WG > never once discussed. I know (cuz I was there) that the authors = intended > unique-stmt to mean 1 leaf instance per unique node. Unfortunately = the language > we thought was precise is ambiguous when nested lists are considered = -- something > the NETMOD WG never did consider. OK, so let's leave it as it is. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Thu Mar 8 08:29:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3421F8730 for ; Thu, 8 Mar 2012 08:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4apMMm3aFNo for ; Thu, 8 Mar 2012 08:29:43 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8FABB21F872B for ; Thu, 8 Mar 2012 08:29:42 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q28GTf0b004013 for ; Thu, 8 Mar 2012 11:29:41 -0500 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59419] helo=[192.168.0.9]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CB/93-29124-47ED85F4; Thu, 08 Mar 2012 11:29:41 -0500 Message-ID: <4F58DE74.7080200@netconfcentral.org> Date: Thu, 08 Mar 2012 08:29:40 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> In-Reply-To: <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:29:43 -0000 On 03/07/2012 10:58 PM, Ladislav Lhotka wrote: > > On Mar 8, 2012, at 7:46 AM, Andy Bierman wrote: > >> I don't and I don't see any value in implementing this error-info element. >> Knowing the list entry (with the unique-stmt) that failed is good enough. > > I agree. Schematron gives an error message of this sort: > > --- Validity error at "/nc:config/t:foo": > Violated uniqueness for "t:a/t:b t:c" > > This is IMO quite enough for locating the problem. > The RFC says list all the non-unique leafs but I'm not going to follow it. Yuma will still support nested lists for yangdump and netconfd validation though. >> >> >> I also think this 'clarification' goes way beyond the bounds of any >> RFC Errata I've ever seen, and I strongly object to that publication mechanism. >> RFC Errata is for things like the missing YANG ABNF comment that says deviation >> sub-statements can appear in any order. That was always the intent of the WG. >> That is clearly indicated in other parts of the draft and nobody disagreed >> that the WG intent was to allow sub-statements in any order. >> >> In this case, new uses for the unique-stmt are being invented that the NETMOD WG >> never once discussed. I know (cuz I was there) that the authors intended >> unique-stmt to mean 1 leaf instance per unique node. Unfortunately the language >> we thought was precise is ambiguous when nested lists are considered -- something >> the NETMOD WG never did consider. > > OK, so let's leave it as it is. > What does that mean wrt/ ietf-routing.yang? I don't mind if that stays as-is I guess, because nobody is very likely to start putting this obscure feature in their data models. > Lada > Andy From lhotka@nic.cz Thu Mar 8 08:45:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBFA21F847D for ; Thu, 8 Mar 2012 08:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlV3l3G8cT+N for ; Thu, 8 Mar 2012 08:45:27 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3B98E21F847C for ; Thu, 8 Mar 2012 08:45:27 -0800 (PST) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 3D43E2A2957; Thu, 8 Mar 2012 17:45:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331225126; bh=hR4ygxyVWrVFtTxWf7ovcvzn4sHJ9Q0frrfX4rsCbBE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=G89DouHirqUhSBouoPWp1puWK3yRgRGlkxsmfUs+aJ78zJ3Ybvyv5YmVlqhZtvcL/ PWEle2lY8CVHHqW2XDb1mKd8L5UN2O8G0ncvJ/sKFgAOLfU8oqY6+16L0jSOFvA9UM GY+2dY2ZFGv5ZELDRkWRR2tc12CKU92ApoWEKAAk= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <4F58DE74.7080200@netconfcentral.org> Date: Thu, 8 Mar 2012 17:45:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:45:27 -0000 On Mar 8, 2012, at 5:29 PM, Andy Bierman wrote: > On 03/07/2012 10:58 PM, Ladislav Lhotka wrote: >>=20 >> On Mar 8, 2012, at 7:46 AM, Andy Bierman wrote: >>=20 >>> I don't and I don't see any value in implementing this error-info = element. >>> Knowing the list entry (with the unique-stmt) that failed is good = enough. >>=20 >> I agree. Schematron gives an error message of this sort: >>=20 >> --- Validity error at "/nc:config/t:foo": >> Violated uniqueness for "t:a/t:b t:c" >>=20 >> This is IMO quite enough for locating the problem. >>=20 >=20 > The RFC says list all the non-unique leafs but I'm not going to follow = it. > Yuma will still support nested lists for yangdump and netconfd = validation though. >=20 >=20 >>>=20 >>>=20 >>> I also think this 'clarification' goes way beyond the bounds of any >>> RFC Errata I've ever seen, and I strongly object to that publication = mechanism. >>> RFC Errata is for things like the missing YANG ABNF comment that = says deviation >>> sub-statements can appear in any order. That was always the intent = of the WG. >>> That is clearly indicated in other parts of the draft and nobody = disagreed >>> that the WG intent was to allow sub-statements in any order. >>>=20 >>> In this case, new uses for the unique-stmt are being invented that = the NETMOD WG >>> never once discussed. I know (cuz I was there) that the authors = intended >>> unique-stmt to mean 1 leaf instance per unique node. Unfortunately = the language >>> we thought was precise is ambiguous when nested lists are considered = -- something >>> the NETMOD WG never did consider. >>=20 >> OK, so let's leave it as it is. >>=20 >=20 > What does that mean wrt/ ietf-routing.yang? I don't know, I guess the WG should decide whether sublists will be = allowed in the next revision of the YANG standard or not. I will then = follow the suit. Lada =20 > I don't mind if that stays as-is I guess, because nobody is > very likely to start putting this obscure feature in their data = models. >=20 >=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Thu Mar 8 17:02:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F48021E801A for ; Thu, 8 Mar 2012 17:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GxXP7Ix--wH for ; Thu, 8 Mar 2012 17:02:58 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8901821E8010 for ; Thu, 8 Mar 2012 17:02:55 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2912sjF017586 for ; Thu, 8 Mar 2012 20:02:54 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:45465] helo=[192.168.0.9]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 48/D3-31061-DB6595F4; Thu, 08 Mar 2012 20:02:54 -0500 Message-ID: <4F5956BD.7020104@netconfcentral.org> Date: Thu, 08 Mar 2012 17:02:53 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> In-Reply-To: <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 01:02:59 -0000 ... >> >> What does that mean wrt/ ietf-routing.yang? > > I don't know, I guess the WG should decide whether sublists will be allowed in the next revision of the YANG standard or not. I will then follow the suit. > I already find the intentional use of siblings with duplicate local names questionable. I also find the duplication of the /interfaces/interface/name hierarchy within the /routing subtree to be rather questionable. This could get very large. IMO, the mapping is backwards. If you want an interface to map to 0 or 1 routers, then just augment the ietf-interfaces module: augment /if:interfaces/if:interface { leaf router-name { type leafref { path "/rt:routing/rt:route/rt:name"; } description "A reference to the name of the logical router for this interface."; } } > Lada > > Andy From lhotka@cesnet.cz Fri Mar 9 01:54:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8340321F8610 for ; Fri, 9 Mar 2012 01:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCEwIz1TPdzX for ; Fri, 9 Mar 2012 01:54:09 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EA64321F860B for ; Fri, 9 Mar 2012 01:54:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D1A035401A7; Fri, 9 Mar 2012 10:54:06 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIuArx5I932C; Fri, 9 Mar 2012 10:54:04 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0A5885401A1; Fri, 9 Mar 2012 10:54:04 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: <4F5956BD.7020104@netconfcentral.org> References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> <4F5956BD.7020104@netconfcentral.org> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Andy Bierman , Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Date: Fri, 09 Mar 2012 10:54:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:54:09 -0000 On Thu, 08 Mar 2012 17:02:53 -0800, Andy Bierman wrote: > ... > >> > >> What does that mean wrt/ ietf-routing.yang? > > > > I don't know, I guess the WG should decide whether sublists will be allowed in the next revision of the YANG standard or not. I will then follow the suit. > > > > I already find the intentional use of siblings with duplicate local names > questionable. I don't know about any such case in the routing-cfg draft, unless you mean lists and leaf-lists. > > I also find the duplication of the /interfaces/interface/name hierarchy within > the /routing subtree to be rather questionable. This could get very > large. > > IMO, the mapping is backwards. > If you want an interface to map to 0 or 1 routers, > then just augment the ietf-interfaces module: > > augment /if:interfaces/if:interface { > leaf router-name { > type leafref { > path "/rt:routing/rt:route/rt:name"; > } > description > "A reference to the name of the logical router for this interface."; > } > } No, I think each router instance has to have its *logical* interfaces readily available, together with their routing-specific configuration. Looking them up repeatedly in the flat list of interfaces classified only through the messy IANA types could get very expensive. Lada > > > > Lada > > > > > > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Mar 9 01:56:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4902221F8613 for ; Fri, 9 Mar 2012 01:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEJmqJ1+7onI for ; Fri, 9 Mar 2012 01:56:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 844B621F860B for ; Fri, 9 Mar 2012 01:56:25 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD0D320D1A; Fri, 9 Mar 2012 10:56:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z6w1Eg6J2MOU; Fri, 9 Mar 2012 10:56:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27A3B20CFC; Fri, 9 Mar 2012 10:56:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 12D721DAB8BC; Fri, 9 Mar 2012 10:56:24 +0100 (CET) Date: Fri, 9 Mar 2012 10:56:24 +0100 From: Juergen Schoenwaelder To: Andy Bierman , Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Message-ID: <20120309095623.GA6147@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> <4F5956BD.7020104@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:56:26 -0000 On Fri, Mar 09, 2012 at 10:54:03AM +0100, Ladislav Lhotka wrote: > > IMO, the mapping is backwards. > > If you want an interface to map to 0 or 1 routers, > > then just augment the ietf-interfaces module: > > > > augment /if:interfaces/if:interface { > > leaf router-name { > > type leafref { > > path "/rt:routing/rt:route/rt:name"; > > } > > description > > "A reference to the name of the logical router for this interface."; > > } > > } > > No, I think each router instance has to have its *logical* interfaces readily available, together with their routing-specific configuration. Looking them up repeatedly in the flat list of interfaces classified only through the messy IANA types could get very expensive. > How are routers doing this today? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Mar 9 02:20:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61B21F861F for ; Fri, 9 Mar 2012 02:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTZQESOJiRbI for ; Fri, 9 Mar 2012 02:20:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A285221F84CF for ; Fri, 9 Mar 2012 02:20:46 -0800 (PST) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id C8A902A30A2; Fri, 9 Mar 2012 11:20:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331288445; bh=oQQiinj5SostpIaH6l2NHX7uWg9utxGGypSB26su7q8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fy2mD0sfi+SKeN2ynKXwaOBv14jzPfq/WKBScXPFYaI8Zs9bWb0K8gyq8QWi5QgJc jLxqNUExRCedDKeMV0dMckAZ6FLIDmjKccWjM1dhHKppOgvyqyQp3eTEJ+5KN9kVVo d7IuMmdnSSzmmrZABIz/g+Wv1URTWa5Vg6zCOrHw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120309095623.GA6147@elstar.local> Date: Fri, 9 Mar 2012 11:20:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <31D15DB8-EA98-4E46-A3E5-1787122D7898@nic.cz> References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> <4F5956BD.7020104@netconfcentral.org> <20120309095623.GA6147@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org, Jonathan.Hansford@generaldynamics.uk.com Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 10:20:47 -0000 On Mar 9, 2012, at 10:56 AM, Juergen Schoenwaelder wrote: > On Fri, Mar 09, 2012 at 10:54:03AM +0100, Ladislav Lhotka wrote: >=20 >>> IMO, the mapping is backwards. >>> If you want an interface to map to 0 or 1 routers, >>> then just augment the ietf-interfaces module: >>>=20 >>> augment /if:interfaces/if:interface { >>> leaf router-name { >>> type leafref { >>> path "/rt:routing/rt:route/rt:name"; >>> } >>> description >>> "A reference to the name of the logical router for this = interface."; >>> } >>> } >>=20 >> No, I think each router instance has to have its *logical* interfaces = readily available, together with their routing-specific configuration. = Looking them up repeatedly in the flat list of interfaces classified = only through the messy IANA types could get very expensive. >>=20 >=20 > How are routers doing this today? JUNOS: set interfaces fe-1/1/3 description "main router interface" set logical-systems LS1 interfaces fe-1/1/3 unit 0 description "LS1 = interface" set logical-systems LS1 interfaces fe-1/1/3 unit 0 family inet address = 10.11.2.2/24 NX-OS: switch(config)# vdc MyVDC switch(config-vdc)# allocate interface ethernet 2/11-1 Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Fri Mar 9 10:55:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C296C21E8099 for ; Fri, 9 Mar 2012 10:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNh79DiCBwog for ; Fri, 9 Mar 2012 10:55:30 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1115721E8097 for ; Fri, 9 Mar 2012 10:55:28 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q29ItS2w032244 for ; Fri, 9 Mar 2012 13:55:28 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:48445] helo=[192.168.0.9]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BC/1D-16767-F125A5F4; Fri, 09 Mar 2012 13:55:28 -0500 Message-ID: <4F5A521F.5070508@netconfcentral.org> Date: Fri, 09 Mar 2012 10:55:27 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phil Shafer , Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> <4F5956BD.7020104@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:55:30 -0000 On 03/09/2012 01:54 AM, Ladislav Lhotka wrote: > On Thu, 08 Mar 2012 17:02:53 -0800, Andy Bierman wrote: >> ... >>>> >>>> What does that mean wrt/ ietf-routing.yang? >>> >>> I don't know, I guess the WG should decide whether sublists will be allowed in the next revision of the YANG standard or not. I will then follow the suit. >>> >> >> I already find the intentional use of siblings with duplicate local names >> questionable. > > I don't know about any such case in the routing-cfg draft, unless you mean lists and leaf-lists. > >> >> I also find the duplication of the /interfaces/interface/name hierarchy within >> the /routing subtree to be rather questionable. This could get very >> large. >> >> IMO, the mapping is backwards. >> If you want an interface to map to 0 or 1 routers, >> then just augment the ietf-interfaces module: >> >> augment /if:interfaces/if:interface { >> leaf router-name { >> type leafref { >> path "/rt:routing/rt:route/rt:name"; >> } >> description >> "A reference to the name of the logical router for this interface."; >> } >> } > > No, I think each router instance has to have its *logical* interfaces readily available, together with their routing-specific configuration. Looking them up repeatedly in the flat list of interfaces classified only through the messy IANA types could get very expensive. > So the router's logical interfaces -- each router/interfaces/interface entry, are separate and not contained in the ietf-interfaces 'interface' entry? I don't like that. If it mirrors the interfaces module then it seems like duplication to me, and corner-cases when it is out of sync. If this was just a mapping between a router and an interface, then why is the container and list needed? router/interfaces/interface? Why not just use a leaf-list router/interface-name: leaf-list interface-name { type if:interface-ref; description "A reference to the name of a configured logical interface."; } } Is this to support vendor-specific augments? Why? They can just augment the /routing/router or /interfaces/interface entry. IMO, it is much better to keep 1 /interfaces/interface entry and have other modules augment that, rather than duplicating this central data structure for each service-specific need. > Lada > Andy From lhotka@nic.cz Fri Mar 9 12:47:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CB721E8044 for ; Fri, 9 Mar 2012 12:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkrPfBenWwFD for ; Fri, 9 Mar 2012 12:47:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0921E80B3 for ; Fri, 9 Mar 2012 12:47:39 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id EBA4A2A00B2; Fri, 9 Mar 2012 21:47:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331326058; bh=eMYvKh2CdXT6S2tcn80VOlELPOev+JbTQrX16MbPf3Q=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bSe9e3blNshSCs6zsXAdL+tGDh48S/ysaW4QvFlqRLiT/84WE5H2TiQ9lq8TE1HG+ dz3U7QZvMeKvHIYnaoD83QS+B7FarHQMg+7uaGfx4OfFe+uJYfc8nCePoS3tNCeMZx DqtU4MWfyoOr6PbOHpYZHDCsV9itaZxsIRpb3qOo= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F5A521F.5070508@netconfcentral.org> Date: Fri, 9 Mar 2012 21:47:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> <4F5956BD.7020104@netconfcentral.org> <4F5A521F.5070508@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 20:47:41 -0000 On Mar 9, 2012, at 7:55 PM, Andy Bierman wrote: > On 03/09/2012 01:54 AM, Ladislav Lhotka wrote: >> On Thu, 08 Mar 2012 17:02:53 -0800, Andy = Bierman wrote: >>> ... >>>>>=20 >>>>> What does that mean wrt/ ietf-routing.yang? >>>>=20 >>>> I don't know, I guess the WG should decide whether sublists will be = allowed in the next revision of the YANG standard or not. I will then = follow the suit. >>>>=20 >>>=20 >>> I already find the intentional use of siblings with duplicate local = names >>> questionable. >>=20 >> I don't know about any such case in the routing-cfg draft, unless you = mean lists and leaf-lists. >>=20 >>>=20 >>> I also find the duplication of the /interfaces/interface/name = hierarchy within >>> the /routing subtree to be rather questionable. This could get very >>> large. >>>=20 >>> IMO, the mapping is backwards. >>> If you want an interface to map to 0 or 1 routers, >>> then just augment the ietf-interfaces module: >>>=20 >>> augment /if:interfaces/if:interface { >>> leaf router-name { >>> type leafref { >>> path "/rt:routing/rt:route/rt:name"; >>> } >>> description >>> "A reference to the name of the logical router for this = interface."; >>> } >>> } >>=20 >> No, I think each router instance has to have its *logical* interfaces = readily available, together with their routing-specific configuration. = Looking them up repeatedly in the flat list of interfaces classified = only through the messy IANA types could get very expensive. >>=20 >=20 >=20 > So the router's logical interfaces -- each router/interfaces/interface = entry, > are separate and not contained in the ietf-interfaces 'interface' = entry? No, see the module, they must all be under "/if:interfaces", and they = are linked from under "/rt:router/rt:interfaces" via leafrefs. > I don't like that. If it mirrors the interfaces module then it seems > like duplication to me, and corner-cases when it is out of sync. >=20 > If this was just a mapping between a router and an interface, then why > is the container and list needed? router/interfaces/interface? It is prepared for augments, you can already see an example in the = module ietf-ipv6-unicast-routing, where router/interfaces/interface is = augmented with configuration of IPv6 router advertisements. > Why not just use a leaf-list router/interface-name: >=20 > leaf-list interface-name { > type if:interface-ref; > description > "A reference to the name of a configured logical > interface."; > } > } >=20 > Is this to support vendor-specific augments? Why? All kinds of augment, not only vendor-specific. >=20 > They can just augment the /routing/router or /interfaces/interface = entry. >=20 > IMO, it is much better to keep 1 /interfaces/interface entry and > have other modules augment that, rather than duplicating this > central data structure for each service-specific need. This is of course subjective but I prefer this design to having = /interfaces/interfaces as a kitchen sink of all interface-related = configuration and state data. Another YANG-specific aspect is that every = extra level of augments makes the data model less comprehensible. And I = think major CLIs follow this design, too, see my previous mail. Lada >=20 >=20 >> Lada >>=20 >=20 >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Fri Mar 9 12:58:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6D321F85B5 for ; Fri, 9 Mar 2012 12:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNq91g2HKrZZ for ; Fri, 9 Mar 2012 12:58:28 -0800 (PST) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5D22621F8517 for ; Fri, 9 Mar 2012 12:58:28 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q29KwReA014221 for ; Fri, 9 Mar 2012 15:58:27 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:49184] helo=[192.168.0.9]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id FF/EC-16767-3FE6A5F4; Fri, 09 Mar 2012 15:58:27 -0500 Message-ID: <4F5A6EF3.1090004@netconfcentral.org> Date: Fri, 09 Mar 2012 12:58:27 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ladislav Lhotka References: <201203061821.q26ILklW053713@idle.juniper.net> <4F569BA4.80102@netconfcentral.org> <4F5855B3.5000902@netconfcentral.org> <97F78CE1-719A-456C-A531-C6D48FF1EAED@nic.cz> <4F58DE74.7080200@netconfcentral.org> <2607CD1C-72E7-4721-B7AD-281277C028D6@nic.cz> <4F5956BD.7020104@netconfcentral.org> <4F5A521F.5070508@netconfcentral.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 20:58:29 -0000 ... >> >> IMO, it is much better to keep 1 /interfaces/interface entry and >> have other modules augment that, rather than duplicating this >> central data structure for each service-specific need. > > This is of course subjective but I prefer this design to having /interfaces/interfaces as a kitchen sink of all interface-related configuration and state data. Another YANG-specific aspect is that every extra level of augments makes the data model less comprehensible. And I think major CLIs follow this design, too, see my previous mail. > It's not a kitchen sink. A common template in networking configs is to have a global component and a per-interface component (or per circuit, per port-profile, etc.) /routing /interfaces/interface/routing The issue is whether it makes sense for an instance of the per-interface routing config to persist even if the interface is deleted. If so, then storing it outside the interface is required. > Lada Andy From phil@juniper.net Fri Mar 9 13:33:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0721E8040 for ; Fri, 9 Mar 2012 13:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdiZdUO5qvCr for ; Fri, 9 Mar 2012 13:33:19 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEAC21E8032 for ; Fri, 9 Mar 2012 13:33:15 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT1p3GSUWOrUDonpVmZ1n3RXQQPRHu0Tj@postini.com; Fri, 09 Mar 2012 13:33:18 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Mar 2012 13:32:45 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q29LWh103883; Fri, 9 Mar 2012 13:32:44 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q29L2L1B085542; Fri, 9 Mar 2012 21:02:22 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201203092102.q29L2L1B085542@idle.juniper.net> To: Andy Bierman In-Reply-To: <4F5A6EF3.1090004@netconfcentral.org> Date: Fri, 9 Mar 2012 16:02:21 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:33:19 -0000 Andy Bierman writes: > /routing > /interfaces/interface/routing This is a major design issue: Interfaces will have protocol information and protocols will have interface information. The choices of where to put which piece can have a huge impact. For example, in JUNOS, interfaces have information about address famiies, but no protocols. So you have: /interfaces/interface/unit/family/inet/address/name /interfaces/interface/unit/family/inet6/address/name /interfaces/interface/unit/family/mpls which is mostly nice, but then you have: /protocols/bgp/group/neighbor/name /protocols/ospf/area/interface/name /protocols/isis/level/interface/name /protocols/pim/interface/name /protocols/ldp/interface/name which is mostly nice. But the annoying past is that configuring MPLS requires one turn on the MPLS address family on the interface, which is simple but the cause of a shocking number of errors. It's rather like a table of rows and columns. Some times it's useful to have the protocols-oriented view and some times it's more useful to have an interface-oriented view. And most of the time it's nice to have things where you use them the most, even if it is a bit inconsistent. Thanks, Phil From andy@netconfcentral.org Sat Mar 10 09:01:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1786A21F8545 for ; Sat, 10 Mar 2012 09:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XFGzsQcpon5 for ; Sat, 10 Mar 2012 09:01:03 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5E46621F853B for ; Sat, 10 Mar 2012 09:01:03 -0800 (PST) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2AH12rd028879 for ; Sat, 10 Mar 2012 12:01:02 -0500 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:53565] helo=[192.168.0.9]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 9A/FE-23992-DC88B5F4; Sat, 10 Mar 2012 12:01:02 -0500 Message-ID: <4F5B88CE.3080002@netconfcentral.org> Date: Sat, 10 Mar 2012 09:01:02 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phil Shafer References: <201203092102.q29L2L1B085542@idle.juniper.net> In-Reply-To: <201203092102.q29L2L1B085542@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netmod@ietf.org Subject: Re: [netmod] YANG issues in draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 17:01:04 -0000 On 03/09/2012 01:02 PM, Phil Shafer wrote: > Andy Bierman writes: >> /routing >> /interfaces/interface/routing > > This is a major design issue: Interfaces will have protocol > information and protocols will have interface information. > The choices of where to put which piece can have a huge impact. > > For example, in JUNOS, interfaces have information about > address famiies, but no protocols. So you have: > > /interfaces/interface/unit/family/inet/address/name > /interfaces/interface/unit/family/inet6/address/name > /interfaces/interface/unit/family/mpls > > which is mostly nice, but then you have: > > /protocols/bgp/group/neighbor/name > /protocols/ospf/area/interface/name > /protocols/isis/level/interface/name > /protocols/pim/interface/name > /protocols/ldp/interface/name > > which is mostly nice. > > But the annoying past is that configuring MPLS requires one turn > on the MPLS address family on the interface, which is simple but > the cause of a shocking number of errors. > > It's rather like a table of rows and columns. Some times it's > useful to have the protocols-oriented view and some times it's > more useful to have an interface-oriented view. And most of > the time it's nice to have things where you use them the most, > even if it is a bit inconsistent. > I like the JUNOS approach. I wish we started with /protocols/netconf instead of /netconf and /netconf-state. This is what we have (some RFC, some I-D): /netconf /netconf-state /ipfix /interfaces /nacm /routing /system /netconf is misleading because it just contains monitoring info about notifications. (So we could not use /netconf/nacm as one might expect.) It looks like there is an interface list under each protocol, as needed. I guess there is complexity either way, so I will drop my objection to /routing/router/interfaces/interface. But I hope we don't end up with a bowl of spaghetti bowls ;-) > Thanks, > Phil > > Andy From jeffrey.K.lange@ge.com Mon Mar 12 11:22:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C871821F885C for ; Mon, 12 Mar 2012 11:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABj3GHmkRcZ7 for ; Mon, 12 Mar 2012 11:22:25 -0700 (PDT) Received: from exprod5og103.obsmtp.com (exprod5og103.obsmtp.com [64.18.0.145]) by ietfa.amsl.com (Postfix) with ESMTP id 34ACC21F8894 for ; Mon, 12 Mar 2012 11:22:25 -0700 (PDT) Received: from cinmlip14.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob103.postini.com ([64.18.4.12]) with SMTP ID DSNKT14+4CjX5dWSx9LznFHeE3bZ1Lzpagh/@postini.com; Mon, 12 Mar 2012 11:22:25 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip14.e2k.ad.ge.com with ESMTP; 12 Mar 2012 14:22:24 -0400 Received: from LOUMLVEM02.e2k.ad.ge.com ([3.159.160.35]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 14:22:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD007D.10F079E2" Date: Mon, 12 Mar 2012 14:22:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-netmod-system-mgmt-00 thread-index: Ac0AfO8+LYcs7QuPRpC4y+aE0qmUxg== From: "Lange, Jeffrey K (GE Energy)" To: X-OriginalArrivalTime: 12 Mar 2012 18:22:23.0566 (UTC) FILETIME=[11F2F6E0:01CD007D] Subject: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:23:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD007D.10F079E2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I was looking over the draft-ietf-netmod-system-mgmt-00 but I had a quick question. How do you envision the DNS and NTP settings being used in a situation where these values are being obtained from a DHCP server? Would a read of these values reflect an admin or an operational state? Should there be some way of specifying that the values should be obtained from DHCP vs a static configuration? =20 Also for any of the containers that use a list of hosts (Radius, ntp) should there be a config false leaf that can show which of the specified servers is actually being used? Although I could see this being more of a implementation specific thing as perhaps some users might use all in some round-robin fashion. I'm just curious if there is any merit in adding that functionality. =20 Thanks! -Jeff Lange =20 ------_=_NextPart_001_01CD007D.10F079E2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

  I = was looking over the draft-ietf-netmod-system-mgmt-00 but I had a quick = question.  How do you envision the DNS and NTP settings being used = in a situation where these values are being obtained from a DHCP = server?  Would a read of these values reflect an admin or an = operational state?  Should there be some way of specifying that the = values should be obtained from DHCP vs a static = configuration?

 

Also for any = of the containers that use a list of hosts (Radius, ntp) should there be = a config false leaf that can show which of the specified servers is = actually being used?  Although I could see this being more of a = implementation specific thing as perhaps some users might use all in = some round-robin fashion.  I’m just curious if there is any = merit in adding that functionality.

 

Thanks!

-Jeff = Lange

 

------_=_NextPart_001_01CD007D.10F079E2-- From andy@netconfcentral.org Mon Mar 12 11:54:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BFF21E8058 for ; Mon, 12 Mar 2012 11:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dVqE-FdVGjV for ; Mon, 12 Mar 2012 11:54:13 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 418B121E8053 for ; Mon, 12 Mar 2012 11:54:13 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2CIsBJ9005069 for ; Mon, 12 Mar 2012 14:54:11 -0400 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:37041] helo=[192.168.0.9]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C4/E1-24163-1564E5F4; Mon, 12 Mar 2012 14:54:10 -0400 Message-ID: <4F5E4651.4090407@netconfcentral.org> Date: Mon, 12 Mar 2012 11:54:09 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Lange, Jeffrey K (GE Energy)" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:54:14 -0000 On 03/12/2012 11:22 AM, Lange, Jeffrey K (GE Energy) wrote: > I was looking over the draft-ietf-netmod-system-mgmt-00 but I had a quick question. How do you envision the DNS and NTP settings being used in a situation where these values are being obtained from a > DHCP server? Would a read of these values reflect an admin or an operational state? Should there be some way of specifying that the values should be obtained from DHCP vs a static configuration? > I agree some sort of 'provided-by-DHCP' option needs to be added. > Also for any of the containers that use a list of hosts (Radius, ntp) should there be a config false leaf that can show which of the specified servers is actually being used? Although I could see > this being more of a implementation specific thing as perhaps some users might use all in some round-robin fashion. I’m just curious if there is any merit in adding that functionality. > We discussed this and then did not add it, not sure how much state information to add. I think you are right -- 'enabled' does not mean 'in-use'. (The old adminStatus/operStatus problem.) > Thanks! > > -Jeff Lange > > Andy From j.schoenwaelder@jacobs-university.de Mon Mar 12 13:01:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A9A21E80CE for ; Mon, 12 Mar 2012 13:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhKlb-JkvZ4V for ; Mon, 12 Mar 2012 13:01:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 813A821E80C5 for ; Mon, 12 Mar 2012 13:01:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5AEFF20C4B; Mon, 12 Mar 2012 21:01:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22PCqEa7TgE9; Mon, 12 Mar 2012 21:01:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E878D20C49; Mon, 12 Mar 2012 21:01:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC0B71DF6E5C; Mon, 12 Mar 2012 21:01:34 +0100 (CET) Date: Mon, 12 Mar 2012 21:01:34 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120312200134.GA70092@elstar.local> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy)" , netmod@ietf.org References: <4F5E4651.4090407@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5E4651.4090407@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:01:37 -0000 On Mon, Mar 12, 2012 at 11:54:09AM -0700, Andy Bierman wrote: > On 03/12/2012 11:22 AM, Lange, Jeffrey K (GE Energy) wrote: > >I was looking over the draft-ietf-netmod-system-mgmt-00 but I had a quick question. How do you envision the DNS and NTP settings being used in a situation where these values are being obtained from a > >DHCP server? Would a read of these values reflect an admin or an operational state? Should there be some way of specifying that the values should be obtained from DHCP vs a static configuration? > > I agree some sort of 'provided-by-DHCP' option needs to be added. I think DHCP provides operational state and not config. Since the YANG definitions are config true, I assume that the DHCP provided operational state does not show up in the config datastore. Sections 4.3 and 4.4 of RFC 6244 might be interesting background reading. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Tue Mar 13 05:57:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC0C21F87BE for ; Tue, 13 Mar 2012 05:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ2ZNrp7TAuA for ; Tue, 13 Mar 2012 05:57:45 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id A10F921F87BF for ; Tue, 13 Mar 2012 05:57:44 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKT19ER09R78MitXoN0kTKQTU2zW/hhrE3@postini.com; Tue, 13 Mar 2012 05:57:45 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip12.e2k.ad.ge.com with ESMTP; 13 Mar 2012 08:57:42 -0400 Received: from LOUMLVEM02.e2k.ad.ge.com ([3.159.160.35]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 08:57:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 08:57:40 -0400 Message-ID: In-Reply-To: <20120312200134.GA70092@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] draft-ietf-netmod-system-mgmt-00 thread-index: Ac0AivBHPirX7rUsQEq9Syw5gYhFkQAjWs4Q References: <4F5E4651.4090407@netconfcentral.org> <20120312200134.GA70092@elstar.local> From: "Lange, Jeffrey K (GE Energy)" To: "Juergen Schoenwaelder" , "Andy Bierman" X-OriginalArrivalTime: 13 Mar 2012 12:57:42.0070 (UTC) FILETIME=[E07C5560:01CD0118] Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 12:57:46 -0000 I agree that DHCP provides operational (config false) info, however I need a config true method of telling my device to either use the DNS/NTP entries from DHCP or to ignore them and to use the static entries. And in an ideal world if I have more than one DHCP interface (on different subnets), I would like to be able to specify which interface I want to use the DHCP DNS/NTP entries from, although I admit, this is a bit more implementation specific.=20 Thanks! -Jeff -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, March 12, 2012 4:02 PM To: Andy Bierman Cc: Lange, Jeffrey K (GE Energy); netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 On Mon, Mar 12, 2012 at 11:54:09AM -0700, Andy Bierman wrote: > On 03/12/2012 11:22 AM, Lange, Jeffrey K (GE Energy) wrote: > >I was looking over the draft-ietf-netmod-system-mgmt-00 but I had a=20 > >quick question. How do you envision the DNS and NTP settings being used in a situation where these values are being obtained from a DHCP server? Would a read of these values reflect an admin or an operational state? Should there be some way of specifying that the values should be obtained from DHCP vs a static configuration? >=20 > I agree some sort of 'provided-by-DHCP' option needs to be added. I think DHCP provides operational state and not config. Since the YANG definitions are config true, I assume that the DHCP provided operational state does not show up in the config datastore. Sections 4.3 and 4.4 of RFC 6244 might be interesting background reading. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 13 06:40:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF12121F88AD for ; Tue, 13 Mar 2012 06:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.213 X-Spam-Level: X-Spam-Status: No, score=-103.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XmBxJ7sZXHA for ; Tue, 13 Mar 2012 06:40:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 13EF721F88AB for ; Tue, 13 Mar 2012 06:40:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01AAB20C35; Tue, 13 Mar 2012 14:40:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id c9JYMDD0EDZp; Tue, 13 Mar 2012 14:40:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6384B20C54; Tue, 13 Mar 2012 14:40:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 709A11DF8BD8; Tue, 13 Mar 2012 14:40:01 +0100 (CET) Date: Tue, 13 Mar 2012 14:40:01 +0100 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120313134001.GA74894@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , Andy Bierman , netmod@ietf.org References: <4F5E4651.4090407@netconfcentral.org> <20120312200134.GA70092@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 13:40:04 -0000 On Tue, Mar 13, 2012 at 08:57:40AM -0400, Lange, Jeffrey K (GE Energy) wrote: > I agree that DHCP provides operational (config false) info, however I > need a config true method of telling my device to either use the DNS/NTP > entries from DHCP or to ignore them and to use the static entries. And > in an ideal world if I have more than one DHCP interface (on different > subnets), I would like to be able to specify which interface I want to > use the DHCP DNS/NTP entries from, although I admit, this is a bit more > implementation specific. My understanding is that right now the I-D does not cover DHCP configuration. If you want to draft a proposal how to cover this, I am sure will be appreciated as potential material to add. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Tue Mar 13 10:52:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0E21F878A for ; Tue, 13 Mar 2012 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXXksMwRw40Z for ; Tue, 13 Mar 2012 10:52:13 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 993B821F8778 for ; Tue, 13 Mar 2012 10:52:09 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT1+JSIKemzs8hf08vnvqwWwLYDfHdh0p@postini.com; Tue, 13 Mar 2012 10:52:09 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 13 Mar 2012 10:52:05 -0700 From: Kent Watsen To: "netmod@ietf.org" Date: Tue, 13 Mar 2012 10:52:03 -0700 Thread-Topic: any way to OR if-feature statements? Thread-Index: Ac0BQf/ApKJKhosVTOyVYvqmp3RlFQ== Message-ID: <84600D05C20FF943918238042D7670FD48B8C1BFF4@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netmod] any way to OR if-feature statements? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 17:52:14 -0000 The cardinality for the if-feature substatement is 0..n and the section 7.1= 8.1 says: "In order for a device to implement a feature that is dependent on any other features (i.e., the feature has one or more "if-feature" sub- statements), the device MUST also implement all the dependant features." Which is an AND, but I want to enable a knob if any one of few features is = supported. =20 Is there any way to model this in YANG? Thanks, Kent From andy@netconfcentral.org Tue Mar 13 11:27:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDA521E805E for ; Tue, 13 Mar 2012 11:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oldFVmr6xoBA for ; Tue, 13 Mar 2012 11:27:52 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 92D6121E8050 for ; Tue, 13 Mar 2012 11:27:52 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2DIRpMW002575 for ; Tue, 13 Mar 2012 14:27:51 -0400 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:40969] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 68/22-06633-6A19F5F4; Tue, 13 Mar 2012 14:27:51 -0400 Message-ID: <4F5F91A7.5090702@netconfcentral.org> Date: Tue, 13 Mar 2012 11:27:51 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD48B8C1BFF4@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48B8C1BFF4@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] any way to OR if-feature statements? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:27:53 -0000 On 03/13/2012 10:52 AM, Kent Watsen wrote: > > The cardinality for the if-feature substatement is 0..n and the section 7.18.1 says: > > "In order for a device to implement a feature that is dependent on any > other features (i.e., the feature has one or more "if-feature" sub- > statements), the device MUST also implement all the dependant > features." > > Which is an AND, but I want to enable a knob if any one of few features is supported. > Is there any way to model this in YANG? You need to make datastore leafs to model each feature-enabled, then use a when-stmt XPath expression instead of if-feature. (yangcli XPath has a 'feature-enabled' function to solve this problem: when "feature-enabled('foomod', 'feature1') or feature-enabled('barmod', 'feature2') or module-enabled('bazmod')"; I will probably add it to the netconfd server at some point. > > Thanks, > Kent > Andy From mbj@tail-f.com Tue Mar 13 13:43:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E84E21F85EC for ; Tue, 13 Mar 2012 13:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjKBjP7hp4gv for ; Tue, 13 Mar 2012 13:43:46 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B2F7321F85EA for ; Tue, 13 Mar 2012 13:43:46 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D83F81200043; Tue, 13 Mar 2012 21:43:44 +0100 (CET) Date: Tue, 13 Mar 2012 21:43:44 +0100 (CET) Message-Id: <20120313.214344.532053704.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:43:51 -0000 Hi, "Lange, Jeffrey K (GE Energy)" wrote: > I was looking over the draft-ietf-netmod-system-mgmt-00 but I had a > quick question. How do you envision the DNS and NTP settings being used > in a situation where these values are being obtained from a DHCP server? > Would a read of these values reflect an admin or an operational > state? The *values* provided by DHCP would be config false, i.e. operational state. However, the fact that DHCP should be used at all would be config data. This needs to be per interface. As Juergen wrote, it is currently not part of the data models we have, but maybe it should be... it is not entirely clear where it would fit though. > Should there be some way of specifying that the values should be > obtained from DHCP vs a static configuration? > > Also for any of the containers that use a list of hosts (Radius, ntp) > should there be a config false leaf that can show which of the specified > servers is actually being used? Although I could see this being more of > a implementation specific thing as perhaps some users might use all in > some round-robin fashion. Actually, if the standard allows an implementation to have this freedom, it must be clear from the data model. For radius, a single leaf indicating which server is being used is maybe not possible. I guess you _could_ keep track of which server you got the last reply from, but I am not sure it is very useful. /martin From mbj@tail-f.com Tue Mar 13 13:45:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA36221F86BE for ; Tue, 13 Mar 2012 13:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDJ90VBasLio for ; Tue, 13 Mar 2012 13:45:42 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 54C9321F86B6 for ; Tue, 13 Mar 2012 13:45:42 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 74F721200043; Tue, 13 Mar 2012 21:45:41 +0100 (CET) Date: Tue, 13 Mar 2012 21:45:40 +0100 (CET) Message-Id: <20120313.214540.312716890.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <4F5E4651.4090407@netconfcentral.org> <20120312200134.GA70092@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:45:43 -0000 "Lange, Jeffrey K (GE Energy)" wrote: > I agree that DHCP provides operational (config false) info, however I > need a config true method of telling my device to either use the DNS/NTP > entries from DHCP or to ignore them and to use the static entries. And > in an ideal world if I have more than one DHCP interface (on different > subnets), I would like to be able to specify which interface I want to > use the DHCP DNS/NTP entries from, although I admit, this is a bit more > implementation specific. If someone made a DHCP config data model, this should be part of that model. I think there is merit in having a standard solution for this. /martin From mbj@tail-f.com Tue Mar 13 13:56:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8208021E8020 for ; Tue, 13 Mar 2012 13:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lGN9e+2eKCr for ; Tue, 13 Mar 2012 13:56:02 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id DA60C21E801F for ; Tue, 13 Mar 2012 13:56:01 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B32B11200043; Tue, 13 Mar 2012 21:56:00 +0100 (CET) Date: Tue, 13 Mar 2012 21:55:59 +0100 (CET) Message-Id: <20120313.215559.180736059.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F5F91A7.5090702@netconfcentral.org> References: <84600D05C20FF943918238042D7670FD48B8C1BFF4@EMBX01-HQ.jnpr.net> <4F5F91A7.5090702@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] any way to OR if-feature statements? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:56:03 -0000 Andy Bierman wrote: > On 03/13/2012 10:52 AM, Kent Watsen wrote: > > > > The cardinality for the if-feature substatement is 0..n and the section 7.18.1 says: > > > > "In order for a device to implement a feature that is dependent on any > > other features (i.e., the feature has one or more "if-feature" sub- > > statements), the device MUST also implement all the dependant > > features." > > > > Which is an AND, but I want to enable a knob if any one of few features is supported. > > Is there any way to model this in YANG? > > You need to make datastore leafs to model each feature-enabled, then use > a when-stmt XPath expression instead of if-feature. I am not sure this works. Maybe if you have a mandatory leaf for this. Anoter hack is to have a special feature for the OR. feature foo-or-bar. It is very unfortunate we didn't cover this in 6020. /martin From j.schoenwaelder@jacobs-university.de Wed Mar 14 01:27:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8360321F86EE for ; Wed, 14 Mar 2012 01:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.214 X-Spam-Level: X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYEf6D03uebe for ; Wed, 14 Mar 2012 01:27:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ADF1D21F86E5 for ; Wed, 14 Mar 2012 01:27:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CB3F20C93; Wed, 14 Mar 2012 09:27:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eAwLNusitP9C; Wed, 14 Mar 2012 09:27:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98F0A20C67; Wed, 14 Mar 2012 09:27:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9B5001DFA0B1; Wed, 14 Mar 2012 09:27:38 +0100 (CET) Date: Wed, 14 Mar 2012 09:27:38 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120314082738.GB77774@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] paris meeting agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 08:27:40 -0000 Hi, I have posted a draft of the meeting agenda for Paris: http://www.ietf.org/proceedings/83/agenda/agenda-83-netmod.txt Please let the chairs know if something needs changes or there are any topics for the open mike at the end of the session. For the document editors, please send us your slides with the open issues well in advance of the meeting so that we can upload slide material well ahead of time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Wed Mar 14 02:51:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A9721F8625 for ; Wed, 14 Mar 2012 02:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_05=-1.11, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylIzKDT63ko8 for ; Wed, 14 Mar 2012 02:51:18 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB8921F8721 for ; Wed, 14 Mar 2012 02:51:17 -0700 (PDT) Received: from host86-151-41-215.range86-151.btcentralplus.com (HELO pc6) ([86.151.41.215]) by c2bthomr07.btconnect.com with SMTP id GUU87114; Wed, 14 Mar 2012 09:51:12 +0000 (GMT) Message-ID: <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Martin Bjorklund" References: <4F5E4651.4090407@netconfcentral.org><20120312200134.GA70092@elstar.local> <20120313.214540.312716890.mbj@tail-f.com> Date: Wed, 14 Mar 2012 09:50:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F606A10.0024, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.14.91218:17:7.944, ip=86.151.41.215, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4F606A11.0116,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:51:19 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, March 13, 2012 9:45 PM > "Lange, Jeffrey K (GE Energy)" wrote: > > I agree that DHCP provides operational (config false) info, however I > > need a config true method of telling my device to either use the DNS/NTP > > entries from DHCP or to ignore them and to use the static entries. And > > in an ideal world if I have more than one DHCP interface (on different > > subnets), I would like to be able to specify which interface I want to > > use the DHCP DNS/NTP entries from, although I admit, this is a bit more > > implementation specific. > > If someone made a DHCP config data model, this should be part of that > model. I think there is merit in having a standard solution for this. I think that this is much wider than DHCP. There is an ongoing debate in IPv6, unresolved after many years, as to which takes precedence, values from DHCP or RA values from a router, and there could be more than one of each (if v6ops ever reach a conclusion, I am sure that we can model it:-). Currently, there is a debate about which of multiple SANs to use with Netconf when a certificate is so configured, something that isms did consider. Then any router may get routing table updates statically, from an IGP, EGP and so on, an issue that Cisco addressed a long time ago. etc etc I think we are usually too narrow in our view, and need to remember that there may be different ways in which configuration information may come in and be prepared to create a suitable list of priorities for cases such as the above and all the others I haven't thought of. Whether there should be something generic for this recurrent issue, or whether each case needs to be taken on its individual merits, I am unsure. By the time we get to a DHCP model, it will be too late. It is when we are modelling e.g. the IPv6 prefix information that we need to recognise that options exist and build them in. Tom Petch > > /martin > From lhotka@nic.cz Wed Mar 14 03:18:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6821F84D7 for ; Wed, 14 Mar 2012 03:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsdYbyFxclP4 for ; Wed, 14 Mar 2012 03:18:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C16B721F84D2 for ; Wed, 14 Mar 2012 03:18:52 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:3dea:c88b:c208:7abe] (unknown [IPv6:2001:1488:ac14:1400:3dea:c88b:c208:7abe]) by mail.nic.cz (Postfix) with ESMTPSA id D55062A30A8; Wed, 14 Mar 2012 11:18:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331720331; bh=FBL7fOulpvV2iX7ztvA9CHEXDYmJ8mEKAjx2PgPAXGw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NQlH/6F0kEVL6J8omGj44ZrML+lR4qeZYB6OtTZEPS0PFkMlkhcyFO+GGxuVJwzcx m2PHm22/bYMhtwrV60Q7Z1oR8ndw3PSn4FTGFvEFtCqfnO8S1X62YIZj7rFulYPXvg D5bo7OkGQfSRgGGqIaE2+eyxgdINsxRGgwvrWMno= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> Date: Wed, 14 Mar 2012 11:18:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF5754A-632F-42DC-8EDB-44093263622C@nic.cz> References: <4F5E4651.4090407@netconfcentral.org><20120312200134.GA70092@elstar.local> <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 10:18:53 -0000 On Mar 14, 2012, at 9:50 AM, t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, March 13, 2012 9:45 PM >> "Lange, Jeffrey K (GE Energy)" wrote: >>> I agree that DHCP provides operational (config false) info, however = I >>> need a config true method of telling my device to either use the = DNS/NTP >>> entries from DHCP or to ignore them and to use the static entries. = And >>> in an ideal world if I have more than one DHCP interface (on = different >>> subnets), I would like to be able to specify which interface I want = to >>> use the DHCP DNS/NTP entries from, although I admit, this is a bit = more >>> implementation specific. >>=20 >> If someone made a DHCP config data model, this should be part of that >> model. I think there is merit in having a standard solution for = this. >=20 > I think that this is much wider than DHCP. There is an ongoing debate = in IPv6, > unresolved after many years, as to which takes precedence, values from = DHCP or > RA values from a router, and there could be more than one of each (if = v6ops ever > reach a conclusion, I am sure that we can model it:-). >=20 > Currently, there is a debate about which of multiple SANs to use with = Netconf > when a certificate is so configured, something that isms did consider. >=20 > Then any router may get routing table updates statically, from an IGP, = EGP and > so on, an issue that Cisco addressed a long time ago. >=20 > etc etc >=20 > I think we are usually too narrow in our view, and need to remember = that there > may be different ways in which configuration information may come in = and be > prepared to create a suitable list of priorities for cases such as the = above and > all the others I haven't thought of. Whether there should be = something generic > for this recurrent issue, or whether each case needs to be taken on = its > individual merits, I am unsure. >=20 > By the time we get to a DHCP model, it will be too late. It is when = we are > modelling e.g. the IPv6 prefix information that we need to recognise = that > options exist and build them in. =46rom the narrow point of view of a datastore schema, it is a plausible = option to leave it to the future DHCP data model to augment a core = module (e.g. system) with a knob that turns DHCP on or off. IMO a more serious problem is with semantics, be it expressed in = descriptions or 'must' statements: for example, semantics of IP address = configuration in the "ip" module alone may be different from the = combination of "ip" and "dhcp", unless the "ip" module really foresees = the integration with "dhcp". Lada >=20 > Tom Petch >=20 >>=20 >> /martin >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Mar 14 03:55:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084421F8746 for ; Wed, 14 Mar 2012 03:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqc41NV87xHc for ; Wed, 14 Mar 2012 03:55:03 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 21E1021F873C for ; Wed, 14 Mar 2012 03:55:02 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6F66012008BF; Wed, 14 Mar 2012 11:55:01 +0100 (CET) Date: Wed, 14 Mar 2012 11:55:01 +0100 (CET) Message-Id: <20120314.115501.554379227389547490.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 10:55:04 -0000 "t.petch" wrote: > I think that this is much wider than DHCP. There is an ongoing debate in IPv6, > unresolved after many years, as to which takes precedence, values from DHCP or > RA values from a router, and there could be more than one of each > (if v6ops ever > reach a conclusion, I am sure that we can model it:-). > > Currently, there is a debate about which of multiple SANs to use with Netconf > when a certificate is so configured, something that isms did consider. > > Then any router may get routing table updates statically, from an IGP, EGP and > so on, an issue that Cisco addressed a long time ago. > > etc etc > > I think we are usually too narrow in our view, and need to remember that there > may be different ways in which configuration information may come in and be > prepared to create a suitable list of priorities for cases such as > the above and > all the others I haven't thought of. Yes we are somewhat narrow - we currently model only the "static", or configured-by-the-operator parts. > Whether there should be something generic > for this recurrent issue, or whether each case needs to be taken on its > individual merits, I am unsure. There are probably some recurring patterns, but I think it needs to be done on a case-by-case basis. Sometimes you might want to merge the dynamically learned info with the configured, sometimes you might want one take precedence over the other, and sometimes the fact that you have configured for example DHCP to return the DNS server addresses means that it should be used instead of the statically configured addresses. > By the time we get to a DHCP model, it will be too late. It is when we are > modelling e.g. the IPv6 prefix information that we need to recognise that > options exist and build them in. So are you saying you think we should try to solve this issue now? I think the *modelling* can be done quite easily - we just have to agree *what* to model... /martin From ietfc@btconnect.com Wed Mar 14 04:46:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53F721F873C for ; Wed, 14 Mar 2012 04:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoGKvoKdAxOg for ; Wed, 14 Mar 2012 04:46:40 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3487521F8707 for ; Wed, 14 Mar 2012 04:46:30 -0700 (PDT) Received: from host86-151-41-215.range86-151.btcentralplus.com (HELO pc6) ([86.151.41.215]) by c2bthomr14.btconnect.com with SMTP id GRB55869; Wed, 14 Mar 2012 11:46:22 +0000 (GMT) Message-ID: <04cd01cd01cf$94ce0480$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ladislav Lhotka" References: <4F5E4651.4090407@netconfcentral.org><20120312200134.GA70092@elstar.local> <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <6BF5754A-632F-42DC-8EDB-44093263622C@nic.cz> Date: Wed, 14 Mar 2012 11:45:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F60850E.007F, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2012.3.14.111220:17:8.317, ip=86.151.41.215, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_24, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4F60850F.0067,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 11:46:40 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" Cc: ; "Martin Bjorklund" ; Sent: Wednesday, March 14, 2012 11:18 AM On Mar 14, 2012, at 9:50 AM, t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, March 13, 2012 9:45 PM >> "Lange, Jeffrey K (GE Energy)" wrote: >>> I agree that DHCP provides operational (config false) info, however I >>> need a config true method of telling my device to either use the DNS/NTP >>> entries from DHCP or to ignore them and to use the static entries. And >>> in an ideal world if I have more than one DHCP interface (on different >>> subnets), I would like to be able to specify which interface I want to >>> use the DHCP DNS/NTP entries from, although I admit, this is a bit more >>> implementation specific. >> >> If someone made a DHCP config data model, this should be part of that >> model. I think there is merit in having a standard solution for this. > > I think that this is much wider than DHCP. There is an ongoing debate in IPv6, > unresolved after many years, as to which takes precedence, values from DHCP or > RA values from a router, and there could be more than one of each (if v6ops ever > reach a conclusion, I am sure that we can model it:-). > > Currently, there is a debate about which of multiple SANs to use with Netconf > when a certificate is so configured, something that isms did consider. > > Then any router may get routing table updates statically, from an IGP, EGP and > so on, an issue that Cisco addressed a long time ago. > > etc etc > > I think we are usually too narrow in our view, and need to remember that there > may be different ways in which configuration information may come in and be > prepared to create a suitable list of priorities for cases such as the above and > all the others I haven't thought of. Whether there should be something generic > for this recurrent issue, or whether each case needs to be taken on its > individual merits, I am unsure. > > By the time we get to a DHCP model, it will be too late. It is when we are > modelling e.g. the IPv6 prefix information that we need to recognise that > options exist and build them in. >From the narrow point of view of a datastore schema, it is a plausible option to leave it to the future DHCP data model to augment a core module (e.g. system) with a knob that turns DHCP on or off. IMO a more serious problem is with semantics, be it expressed in descriptions or 'must' statements: for example, semantics of IP address configuration in the "ip" module alone may be different from the combination of "ip" and "dhcp", unless the "ip" module really foresees the integration with "dhcp". I am saying that when we specify the configuring of IP (I know, this thread is system mgt), we should be alive to this situation. In the case of IPv6, the WG are trying to come up with protocol rules about precedence of configuration and have defined two bits to control this and have failed to reach a consensus, over many years, because different uses of IPv6 have different requirements. It is dead obvious (to me:-) that they need a configurable table, as Cisco specify for routing table entries, which gives a default set of rules for precedence and allow the user to configure a different set, at least by protocol, perhaps by some other criterion within the protocol, as for example the absolute value of router id is used as a tie breaker in routing protocols to decide which router should be used. As long as IPv6 try to achieve by protocol what is probably unachievable, then there is nothing we can do for them; if and when they accept the need for configuration, then we should provide the mechanics as in a table of precedence. Even if they do not accept the need, we should probably provide a history saying that this value (e.g. prefix) came from e.g. DHCP or RA or static or ...... The original question here was about NTP and Martin suggested that that would be part of the DHCP model as and when we did one. Wrong (IMHO)! it is part of the NTP model to specify what the order of precedence should be when the box has multiple sources of data. That is what I want us to be alive to, for IPv6, for routing and for .... Tom Petch Lada > > Tom Petch > >> >> /martin >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Wed Mar 14 05:00:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220AA21F874C for ; Wed, 14 Mar 2012 05:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmpiqdJ8KYSM for ; Wed, 14 Mar 2012 05:00:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2649221F873E for ; Wed, 14 Mar 2012 05:00:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8C8F854065A; Wed, 14 Mar 2012 13:00:14 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOot3DWg01aN; Wed, 14 Mar 2012 13:00:07 +0100 (CET) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6CE44540075; Wed, 14 Mar 2012 13:00:07 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , andy@netconfcentral.org In-Reply-To: <20120313.215559.180736059.mbj@tail-f.com> References: <84600D05C20FF943918238042D7670FD48B8C1BFF4@EMBX01-HQ.jnpr.net> <4F5F91A7.5090702@netconfcentral.org> <20120313.215559.180736059.mbj@tail-f.com> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.org, netmod@ietf.org Date: Wed, 14 Mar 2012 13:00:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] any way to OR if-feature statements? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:00:18 -0000 On Tue, 13 Mar 2012 21:55:59 +0100 (CET), Martin Bjorklund wrote: > Andy Bierman wrote: > > On 03/13/2012 10:52 AM, Kent Watsen wrote: > > > > > > The cardinality for the if-feature substatement is 0..n and the section 7.18.1 says: > > > > > > "In order for a device to implement a feature that is dependent on any > > > other features (i.e., the feature has one or more "if-feature" sub- > > > statements), the device MUST also implement all the dependant > > > features." > > > > > > Which is an AND, but I want to enable a knob if any one of few features is supported. > > > Is there any way to model this in YANG? > > > > You need to make datastore leafs to model each feature-enabled, then use > > a when-stmt XPath expression instead of if-feature. > > I am not sure this works. Maybe if you have a mandatory leaf for > this. Anoter hack is to have a special feature for the OR. feature > foo-or-bar. > > It is very unfortunate we didn't cover this in 6020. I think we badly need to standardize a handful of XPath extension function, otherwise things like features, instance-identifiers etc. are sort of crippled. Could it be an option to extend the charter with it? Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Mar 14 05:07:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0C521F8758 for ; Wed, 14 Mar 2012 05:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTEtRPAwaouq for ; Wed, 14 Mar 2012 05:07:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id DCF4921F8757 for ; Wed, 14 Mar 2012 05:07:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9656312008BC; Wed, 14 Mar 2012 13:07:23 +0100 (CET) Date: Wed, 14 Mar 2012 13:07:23 +0100 (CET) Message-Id: <20120314.130723.2316254299484661.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <04cd01cd01cf$94ce0480$4001a8c0@gateway.2wire.net> References: <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <6BF5754A-632F-42DC-8EDB-44093263622C@nic.cz> <04cd01cd01cf$94ce0480$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:07:25 -0000 "t.petch" wrote: > The original question here was about NTP and Martin suggested that > that would be > part of the DHCP model as and when we did one. I don't think that was what I wrote. But it doesn't matter - I agree with you that the precedence thingie should not be part of the DHCP model. The precedence cannot really be part of any of the mechanisms we define (DHCP, RA, ...) - but should it be part of the static configuration? That's also just one mechanism... /martin From lhotka@cesnet.cz Wed Mar 14 06:19:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B19B21F8581 for ; Wed, 14 Mar 2012 06:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLlwZmzkp6mJ for ; Wed, 14 Mar 2012 06:19:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E5BCA21F851A for ; Wed, 14 Mar 2012 06:19:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B935554065A; Wed, 14 Mar 2012 14:18:59 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inScZvvHve4E; Wed, 14 Mar 2012 14:18:45 +0100 (CET) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 85DEC5400F1; Wed, 14 Mar 2012 14:18:45 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , ietfc@btconnect.com In-Reply-To: <20120314.115501.554379227389547490.mbj@tail-f.com> References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <20120314.115501.554379227389547490.mbj@tail-f.com> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , ietfc@btconnect.com, netmod@ietf.org Date: Wed, 14 Mar 2012 14:18:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:19:01 -0000 On Wed, 14 Mar 2012 11:55:01 +0100 (CET), Martin Bjorklund wrote: > > > By the time we get to a DHCP model, it will be too late. It is when we are > > modelling e.g. the IPv6 prefix information that we need to recognise that > > options exist and build them in. > > So are you saying you think we should try to solve this issue now? On thing we should probably tackle is a representation of IP addresses as state data. Many subsystems will need to refer to addresses assigned to interfaces but currently the addresses are not available anywhere in the data tree unless they are manually configured. Even without DHCP, this can already happen for autoconfigured IPv6 addresses. The "ip" module seems to be the right place for such a config=false structure. Lada > > I think the *modelling* can be done quite easily - we just have to > agree *what* to model... > > > > /martin > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@netconfcentral.org Wed Mar 14 08:30:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1F21F87A8 for ; Wed, 14 Mar 2012 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtpKgcUwaXXK for ; Wed, 14 Mar 2012 08:30:21 -0700 (PDT) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA3521F877F for ; Wed, 14 Mar 2012 08:30:20 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q2EFUC3f031490 for ; Wed, 14 Mar 2012 11:30:13 -0400 Authentication-Results: cm-omr2 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:44279] helo=[192.168.0.9]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C5/5D-24083-D79B06F4; Wed, 14 Mar 2012 11:30:09 -0400 Message-ID: <4F60B97F.7080202@netconfcentral.org> Date: Wed, 14 Mar 2012 08:30:07 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Bjorklund References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <20120314.115501.554379227389547490.mbj@tail-f.com> In-Reply-To: <20120314.115501.554379227389547490.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:30:23 -0000 On 03/14/2012 03:55 AM, Martin Bjorklund wrote: > "t.petch" wrote: >> I think that this is much wider than DHCP. There is an ongoing debate in IPv6, >> unresolved after many years, as to which takes precedence, values from DHCP or >> RA values from a router, and there could be more than one of each >> (if v6ops ever >> reach a conclusion, I am sure that we can model it:-). >> >> Currently, there is a debate about which of multiple SANs to use with Netconf >> when a certificate is so configured, something that isms did consider. >> >> Then any router may get routing table updates statically, from an IGP, EGP and >> so on, an issue that Cisco addressed a long time ago. >> >> etc etc >> >> I think we are usually too narrow in our view, and need to remember that there >> may be different ways in which configuration information may come in and be >> prepared to create a suitable list of priorities for cases such as >> the above and >> all the others I haven't thought of. > > Yes we are somewhat narrow - we currently model only the "static", or > configured-by-the-operator parts. > >> Whether there should be something generic >> for this recurrent issue, or whether each case needs to be taken on its >> individual merits, I am unsure. > > There are probably some recurring patterns, but I think it needs to be > done on a case-by-case basis. Sometimes you might want to merge the > dynamically learned info with the configured, sometimes you might want > one take precedence over the other, and sometimes the fact that you > have configured for example DHCP to return the DNS server addresses > means that it should be used instead of the statically configured > addresses. > >> By the time we get to a DHCP model, it will be too late. It is when we are >> modelling e.g. the IPv6 prefix information that we need to recognise that >> options exist and build them in. > > So are you saying you think we should try to solve this issue now? > > I think the *modelling* can be done quite easily - we just have to > agree *what* to model... > > Something like: leaf learn-from-dhcp { type bits { bit addressing { description "Use IP addressing information from DHCP if available."; } bit dns { description "Use DNS information from DHCP if available."; } // any others? } // any default? } > > /martin Andy From j.schoenwaelder@jacobs-university.de Wed Mar 14 08:56:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE4721F861A for ; Wed, 14 Mar 2012 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjhCK4JKEH6T for ; Wed, 14 Mar 2012 08:56:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8C21F85D6 for ; Wed, 14 Mar 2012 08:56:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C47520C87; Wed, 14 Mar 2012 16:56:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZTWDq0wfqODf; Wed, 14 Mar 2012 16:56:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12AD020C7E; Wed, 14 Mar 2012 16:56:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 040521DFCDC5; Wed, 14 Mar 2012 16:56:49 +0100 (CET) Date: Wed, 14 Mar 2012 16:56:49 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120314155649.GA1206@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F60B97F.7080202@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:56:54 -0000 On Wed, Mar 14, 2012 at 08:30:07AM -0700, Andy Bierman wrote: > Something like: > > leaf learn-from-dhcp { > type bits { > bit addressing { > description "Use IP addressing information from DHCP if available."; > } > bit dns { > description "Use DNS information from DHCP if available."; > } > // any others? > } > // any default? > } That looks a bit too simplistic to me. DHCP is used widely and I would be not surprised if for many usages the only config choice is really just DHCP on/off for most users. Once we go beyond on/off, I think the world is not that simple anymore. And in fact, you configure your DHCP client what it requests. How that information is then _used_ if provided by the server especially, if it competes with other information, is the v6ops problem. So the text would be really "obtain xxx information" rather than "use xxx information" (and the proper way of modeling is likely to list the DHCP options that are requests or provided as hints to the DHCP server, that is it goes beyond a simple bits type. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Wed Mar 14 08:58:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3CB21F86B9 for ; Wed, 14 Mar 2012 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALCI0WsMJ8lk for ; Wed, 14 Mar 2012 08:58:46 -0700 (PDT) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by ietfa.amsl.com (Postfix) with ESMTP id C584D21F86B5 for ; Wed, 14 Mar 2012 08:58:45 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKT2DANUKYppgMnftCUXeLFkXV/PX3MsnJ@postini.com; Wed, 14 Mar 2012 08:58:45 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by alpmlip14.e2k.ad.ge.com with ESMTP; 14 Mar 2012 11:58:43 -0400 Received: from LOUMLVEM02.e2k.ad.ge.com ([3.159.160.35]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 11:58:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 11:58:41 -0400 Message-ID: In-Reply-To: <4F60B97F.7080202@netconfcentral.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] draft-ietf-netmod-system-mgmt-00 thread-index: Ac0B927n837+vNL9Si6nKbLfRz6mgwAAQOtA References: <20120313.214540.312716890.mbj@tail-f.com><047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net><20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> From: "Lange, Jeffrey K (GE Energy)" To: "Andy Bierman" , "Martin Bjorklund" X-OriginalArrivalTime: 14 Mar 2012 15:58:43.0088 (UTC) FILETIME=[5491E900:01CD01FB] Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:58:46 -0000 >Something like: > > leaf learn-from-dhcp { > type bits { > bit addressing { > description "Use IP addressing information from DHCP if available."; > } > bit dns { > description "Use DNS information from DHCP if available."; > } > // any others? > } > // any default? > } This wouldn't address the more generic priority issue, What if there was something like: grouping settings-priority { list settings-priority-list { ordered-by user; leaf source-type{ type enumeration { enum static; enum dhcp; enum ...; } } leaf source-iface { // this could be used if you want to specify a particular interface type leaf-ref { path "/interface/name"; } } } } ... container ntp { leaf use-ntp { ... } list ntp-server { ... }=20 leaf enabled { ... } uses settings-priority; } } From andy@netconfcentral.org Wed Mar 14 09:35:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562D721F8744 for ; Wed, 14 Mar 2012 09:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul0V-Fr95VdP for ; Wed, 14 Mar 2012 09:35:27 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id C5B1F21F86F3 for ; Wed, 14 Mar 2012 09:35:27 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2EGZQ80005101 for ; Wed, 14 Mar 2012 12:35:26 -0400 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:44428] helo=[192.168.0.9]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 25/64-23992-EC8C06F4; Wed, 14 Mar 2012 12:35:26 -0400 Message-ID: <4F60C8CF.1070307@netconfcentral.org> Date: Wed, 14 Mar 2012 09:35:27 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Bjorklund , netmod@ietf.org References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> <20120314155649.GA1206@elstar.local> In-Reply-To: <20120314155649.GA1206@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:35:28 -0000 On 03/14/2012 08:56 AM, Juergen Schoenwaelder wrote: > On Wed, Mar 14, 2012 at 08:30:07AM -0700, Andy Bierman wrote: > >> Something like: >> >> leaf learn-from-dhcp { >> type bits { >> bit addressing { >> description "Use IP addressing information from DHCP if available."; >> } >> bit dns { >> description "Use DNS information from DHCP if available."; >> } >> // any others? >> } >> // any default? >> } > > That looks a bit too simplistic to me. DHCP is used widely and I would > be not surprised if for many usages the only config choice is really > just DHCP on/off for most users. Once we go beyond on/off, I think the > world is not that simple anymore. And in fact, you configure your DHCP > client what it requests. How that information is then _used_ if > provided by the server especially, if it competes with other > information, is the v6ops problem. So the text would be really "obtain > xxx information" rather than "use xxx information" (and the proper way > of modeling is likely to list the DHCP options that are requests or > provided as hints to the DHCP server, that is it goes beyond a simple > bits type. > The GUI in Ubuntu has "Automatic (DHCP)" and "Automatic (DHCP) Addresses Only". I think Fedora has the same thing. So maybe it is an enumeration: leaf learn-from-dhcp { type enumeration { enum none { description "Do not use DHCP"; } enum addressing { description "Use IP addressing information from DHCP if available."; } enum addressing-and-dns { description "Use IP addressing information and DNS information from DHCP if available."; } } } > /js > Andy From phil@juniper.net Wed Mar 14 09:45:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706DB21F8535 for ; Wed, 14 Mar 2012 09:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwEaLorGFWn3 for ; Wed, 14 Mar 2012 09:45:51 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9C21F8528 for ; Wed, 14 Mar 2012 09:45:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT2DLLeyQSgQTZqMlnczxi/z4uN5sqDSj@postini.com; Wed, 14 Mar 2012 09:45:51 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 14 Mar 2012 09:45:14 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q2EGjD187378; Wed, 14 Mar 2012 09:45:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q2EGElRl023513; Wed, 14 Mar 2012 16:14:47 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201203141614.q2EGElRl023513@idle.juniper.net> To: Andy Bierman In-Reply-To: <4F60C8CF.1070307@netconfcentral.org> Date: Wed, 14 Mar 2012 12:14:47 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:45:52 -0000 Andy Bierman writes: >The GUI in Ubuntu has "Automatic (DHCP)" and "Automatic (DHCP) Addresses Only". >I think Fedora has the same thing. So maybe it is an enumeration: FWIW: The ISC dhclient allows you to override/ignore any option returned from the server. Here's a good write-up: http://www.lamolabs.org/blog/6194/how-to-override-dhcp-settings-on-a-fedoracentosrhel-linux-box/ I keep home name, domain name, etc, getting only dns, router, and address. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Mar 14 09:47:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAFD21F8831 for ; Wed, 14 Mar 2012 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KumNTeLGQZi8 for ; Wed, 14 Mar 2012 09:47:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB5E21F8836 for ; Wed, 14 Mar 2012 09:47:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEAED20C99; Wed, 14 Mar 2012 17:47:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o_yUq0WOwVdx; Wed, 14 Mar 2012 17:47:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52C7820C80; Wed, 14 Mar 2012 17:47:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4931F1DFDFFA; Wed, 14 Mar 2012 17:47:35 +0100 (CET) Date: Wed, 14 Mar 2012 17:47:35 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120314164735.GB1650@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> <20120314155649.GA1206@elstar.local> <4F60C8CF.1070307@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F60C8CF.1070307@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:47:37 -0000 On Wed, Mar 14, 2012 at 09:35:27AM -0700, Andy Bierman wrote: > On 03/14/2012 08:56 AM, Juergen Schoenwaelder wrote: > >On Wed, Mar 14, 2012 at 08:30:07AM -0700, Andy Bierman wrote: > > > >>Something like: > >> > >> leaf learn-from-dhcp { > >> type bits { > >> bit addressing { > >> description "Use IP addressing information from DHCP if available."; > >> } > >> bit dns { > >> description "Use DNS information from DHCP if available."; > >> } > >> // any others? > >> } > >> // any default? > >> } > > > >That looks a bit too simplistic to me. DHCP is used widely and I would > >be not surprised if for many usages the only config choice is really > >just DHCP on/off for most users. Once we go beyond on/off, I think the > >world is not that simple anymore. And in fact, you configure your DHCP > >client what it requests. How that information is then _used_ if > >provided by the server especially, if it competes with other > >information, is the v6ops problem. So the text would be really "obtain > >xxx information" rather than "use xxx information" (and the proper way > >of modeling is likely to list the DHCP options that are requests or > >provided as hints to the DHCP server, that is it goes beyond a simple > >bits type. > > > > The GUI in Ubuntu has "Automatic (DHCP)" and "Automatic (DHCP) Addresses Only". > I think Fedora has the same thing. So maybe it is an enumeration: > > leaf learn-from-dhcp { > type enumeration { > enum none { > description "Do not use DHCP"; > } > enum addressing { > description "Use IP addressing information from DHCP if available."; > } > enum addressing-and-dns { > description "Use IP addressing information and DNS information > from DHCP if available."; > } > } > } > > >/js I am not sure a GUI is the right model. Linus systems using the Debian(?) interfaces config have this (quoting from interfaces(5)): The dhcp Method This method may be used to obtain an address via DHCP with any of the tools: dhclient, pump, udhcpc, dhcpcd. (They have been listed in their order of precedence.) If you have a complicated DHCP setup you should note that some of these clients use their own configuration files and do not obtain their configuration information via ifup. Options hostname hostname Hostname to be requested (pump, dhcpcd, udhcpc) leasehours leasehours Preferred lease time in hours (pump) leasetime leasetime Preferred lease time in seconds (dhcpcd) vendor vendor Vendor class identifier (dhcpcd) client client Client identifier (dhcpcd, udhcpc) hwaddress class address Hardware Address. class is one of ether, ax25, ARCnet or netrom. address is dependent on this choice. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Wed Mar 14 10:12:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D503B21E8010 for ; Wed, 14 Mar 2012 10:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqTXu8xSfcFv for ; Wed, 14 Mar 2012 10:12:00 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE7621F86C6 for ; Wed, 14 Mar 2012 10:11:47 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2EHBk2M025507 for ; Wed, 14 Mar 2012 13:11:46 -0400 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:44738] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 8A/8B-14799-251D06F4; Wed, 14 Mar 2012 13:11:46 -0400 Message-ID: <4F60D154.8050208@netconfcentral.org> Date: Wed, 14 Mar 2012 10:11:48 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Bjorklund , netmod@ietf.org References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> <20120314155649.GA1206@elstar.local> <4F60C8CF.1070307@netconfcentral.org> <20120314164735.GB1650@elstar.local> In-Reply-To: <20120314164735.GB1650@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:12:01 -0000 On 03/14/2012 09:47 AM, Juergen Schoenwaelder wrote: > On Wed, Mar 14, 2012 at 09:35:27AM -0700, Andy Bierman wrote: >> On 03/14/2012 08:56 AM, Juergen Schoenwaelder wrote: >>> On Wed, Mar 14, 2012 at 08:30:07AM -0700, Andy Bierman wrote: >>> >>>> Something like: >>>> >>>> leaf learn-from-dhcp { >>>> type bits { >>>> bit addressing { >>>> description "Use IP addressing information from DHCP if available."; >>>> } >>>> bit dns { >>>> description "Use DNS information from DHCP if available."; >>>> } >>>> // any others? >>>> } >>>> // any default? >>>> } >>> >>> That looks a bit too simplistic to me. DHCP is used widely and I would >>> be not surprised if for many usages the only config choice is really >>> just DHCP on/off for most users. Once we go beyond on/off, I think the >>> world is not that simple anymore. And in fact, you configure your DHCP >>> client what it requests. How that information is then _used_ if >>> provided by the server especially, if it competes with other >>> information, is the v6ops problem. So the text would be really "obtain >>> xxx information" rather than "use xxx information" (and the proper way >>> of modeling is likely to list the DHCP options that are requests or >>> provided as hints to the DHCP server, that is it goes beyond a simple >>> bits type. >>> >> >> The GUI in Ubuntu has "Automatic (DHCP)" and "Automatic (DHCP) Addresses Only". >> I think Fedora has the same thing. So maybe it is an enumeration: >> >> leaf learn-from-dhcp { >> type enumeration { >> enum none { >> description "Do not use DHCP"; >> } >> enum addressing { >> description "Use IP addressing information from DHCP if available."; >> } >> enum addressing-and-dns { >> description "Use IP addressing information and DNS information >> from DHCP if available."; >> } >> } >> } >> >>> /js > > I am not sure a GUI is the right model. Linus systems using the > Debian(?) interfaces config have this (quoting from interfaces(5)): > > The dhcp Method > This method may be used to obtain an address via DHCP with any of the > tools: dhclient, pump, udhcpc, dhcpcd. (They have been listed in their > order of precedence.) If you have a complicated DHCP setup you should > note that some of these clients use their own configuration files and > do not obtain their configuration information via ifup. > > Options > > hostname hostname > Hostname to be requested (pump, dhcpcd, udhcpc) > > leasehours leasehours > Preferred lease time in hours (pump) > > leasetime leasetime > Preferred lease time in seconds (dhcpcd) > > vendor vendor > Vendor class identifier (dhcpcd) > > client client > Client identifier (dhcpcd, udhcpc) > > hwaddress class address > Hardware Address. class is one of ether, ax25, ARCnet or > netrom. address is dependent on this choice. > This module is about the system configuration, not the DHCP configuration. A prioritized list of configuration sources is a system knob. I was trying to pick a couple system options that are very widely supported. > /js > Andy From j.schoenwaelder@jacobs-university.de Wed Mar 14 10:39:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACE021F8770 for ; Wed, 14 Mar 2012 10:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfrhBMThlktB for ; Wed, 14 Mar 2012 10:39:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 362E921F876C for ; Wed, 14 Mar 2012 10:39:47 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87C8720C9B; Wed, 14 Mar 2012 18:39:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zrRYi8hSwYEj; Wed, 14 Mar 2012 18:39:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 078E120C85; Wed, 14 Mar 2012 18:39:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E8C791DFE37C; Wed, 14 Mar 2012 18:39:45 +0100 (CET) Date: Wed, 14 Mar 2012 18:39:45 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120314173945.GA2012@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <20120313.214540.312716890.mbj@tail-f.com> <047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net> <20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> <20120314155649.GA1206@elstar.local> <4F60C8CF.1070307@netconfcentral.org> <20120314164735.GB1650@elstar.local> <4F60D154.8050208@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F60D154.8050208@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:39:48 -0000 On Wed, Mar 14, 2012 at 10:11:48AM -0700, Andy Bierman wrote: > This module is about the system configuration, not the DHCP configuration. > A prioritized list of configuration sources is a system knob. > I was trying to pick a couple system options that are very widely supported. The question is likely whether the model is the average GUI on a desktop OS or the average CLI of routers/switches and the like. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Mar 14 11:56:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65C21F84E2 for ; Wed, 14 Mar 2012 11:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G92IsKd+03K for ; Wed, 14 Mar 2012 11:56:39 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 82A4A21F84E4 for ; Wed, 14 Mar 2012 11:56:39 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EC1FD12008BC; Wed, 14 Mar 2012 19:56:37 +0100 (CET) Date: Wed, 14 Mar 2012 19:56:37 +0100 (CET) Message-Id: <20120314.195637.263825083.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 18:56:40 -0000 "Lange, Jeffrey K (GE Energy)" wrote: > >Something like: > > > > leaf learn-from-dhcp { > > type bits { > > bit addressing { > > description "Use IP addressing information from DHCP if > available."; > > } > > bit dns { > > description "Use DNS information from DHCP if available."; > > } > > // any others? > > } > > // any default? > > } > > This wouldn't address the more generic priority issue, Right. Andy's leaf targets the DHCP client config (which I think should go into some other data model). > What if there was something like: > > grouping settings-priority { > list settings-priority-list { > ordered-by user; > leaf source-type{ > type enumeration { > enum static; > enum dhcp; > enum ...; > } > } Yes, but it can be made more extensible by using identities (see 'user-authentication-order' in draft-ietf-netmod-system-mgmt). leaf-list settings-priority { type identityref { base settings-priority-mechanism; } } identity from-config { base settings-priority-mechanism; } identity dhcp { base settings-priority-mechanism; } identity ra { base settings-priority-mechanism; } By using this model, whenever a new mechanism is modelled, a new identity can be defined (in some other model) along with the config for that mechanism: /martin From lhotka@nic.cz Wed Mar 14 12:23:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61F621F87DF for ; Wed, 14 Mar 2012 12:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n7GwhVOhTJR for ; Wed, 14 Mar 2012 12:23:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6C21F87DE for ; Wed, 14 Mar 2012 12:23:10 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 40CC82A01AF; Wed, 14 Mar 2012 20:23:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331752989; bh=FCvjobVH/FJbXQhmUI8zAAyq5rMOvNJDd/mpMTuulXo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cs6HS/UNX9Qx2LRLZCA5DyrDS2gVN5nB6nIUqH8FlHQ8Jxif8FBMvce9Fm4caRRBw DHErosj6ffyWnjYTu6f+jWIeSqfoMGzJWVPySGGWk6BByg+IjAPWhJg1KzBlcmtcCX 6B5O9FfjORUhnRv9qjshNYVzC8kBqVH0KFQBY2+k= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120314.195637.263825083.mbj@tail-f.com> Date: Wed, 14 Mar 2012 20:23:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120314.115501.554379227389547490.mbj@tail-f.com> <4F60B97F.7080202@netconfcentral.org> <20120314.195637.263825083.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:23:12 -0000 On Mar 14, 2012, at 7:56 PM, Martin Bjorklund wrote: > "Lange, Jeffrey K (GE Energy)" wrote: >>> Something like: >>>=20 >>> leaf learn-from-dhcp { >>> type bits { >>> bit addressing { >>> description "Use IP addressing information from DHCP if >> available."; >>> } >>> bit dns { >>> description "Use DNS information from DHCP if available."; >>> } >>> // any others? >>> } >>> // any default? >>> } >>=20 >> This wouldn't address the more generic priority issue, >=20 > Right. Andy's leaf targets the DHCP client config (which I think > should go into some other data model). >=20 >=20 >> What if there was something like: >>=20 >> grouping settings-priority { >> list settings-priority-list { >> ordered-by user; >> leaf source-type{ >> type enumeration { >> enum static; >> enum dhcp; >> enum ...; >> } >> } >=20 > Yes, but it can be made more extensible by using identities (see > 'user-authentication-order' in draft-ietf-netmod-system-mgmt). >=20 > leaf-list settings-priority { > type identityref { > base settings-priority-mechanism; > } > } >=20 > identity from-config { > base settings-priority-mechanism; > } >=20 > identity dhcp { > base settings-priority-mechanism; > } >=20 > identity ra { > base settings-priority-mechanism; > } >=20 > By using this model, whenever a new mechanism is modelled, a new > identity can be defined (in some other model) along with the config > for that mechanism: Identities are nice but they do not work reliably in XPath expressions, = and this would be a problem in this case. Lada =20 >=20 >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Sat Mar 17 05:36:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7814021F8699 for ; Sat, 17 Mar 2012 05:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVnYiLzFxt5X for ; Sat, 17 Mar 2012 05:36:18 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 672CF21F8698 for ; Sat, 17 Mar 2012 05:36:17 -0700 (PDT) Received: from host86-151-41-215.range86-151.btcentralplus.com (HELO pc6) ([86.151.41.215]) by c2bthomr10.btconnect.com with SMTP id GTX43014; Sat, 17 Mar 2012 12:36:13 +0000 (GMT) Message-ID: <014e01cd0432$087873c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Andy Bierman" References: <20120313.214540.312716890.mbj@tail-f.com><047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net><20120314.115501.554379227389547490.mbj@tail-f.com><4F60B97F.7080202@netconfcentral.org> <20120314155649.GA1206@elstar.local> Date: Sat, 17 Mar 2012 12:35:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F64853A.005A, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.17.115414:17:7.944, ip=86.151.41.215, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4F64853D.010C,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 12:36:19 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Andy Bierman" Cc: Sent: Wednesday, March 14, 2012 4:56 PM > On Wed, Mar 14, 2012 at 08:30:07AM -0700, Andy Bierman wrote: > > > Something like: > > > > leaf learn-from-dhcp { > > type bits { > > bit addressing { > > description "Use IP addressing information from DHCP if available."; > > } > > bit dns { > > description "Use DNS information from DHCP if available."; > > } > > // any others? > > } > > // any default? > > } > > That looks a bit too simplistic to me. DHCP is used widely and I would > be not surprised if for many usages the only config choice is really > just DHCP on/off for most users. Once we go beyond on/off, I think the > world is not that simple anymore. And in fact, you configure your DHCP > client what it requests. How that information is then _used_ if > provided by the server especially, if it competes with other > information, is the v6ops problem. So the text would be really "obtain > xxx information" rather than "use xxx information" (and the proper way > of modeling is likely to list the DHCP options that are requests or > provided as hints to the DHCP server, that is it goes beyond a simple > bits type. This is more like what I was thinking of, that there is DHCP configuration/state but that there is also configuration/state for the protocols for which DHCP provides raw data. The DHCP module would specify what DHCP options should be requested and what data came back in response, while the module for the other protocols would specify the mechanism for selecting between which of several options should be chosen in order to arrive at a configuration. IPv6, in its attempt to be auto-configuring, has created such a situation, with the prefix, which could come from a router RA (or more than one) or from DHCP and the WG cannot produce a set of rules which satisfy the varying needs; and something similar arises with address selection, which of the many possible source and destination address pairs should be used for a packet. The case we already have is the selection of security credentials for SNMP over TLS, snmpTlstmCertToTSNTable, (not that I expect to see that modelled in yang any time soon:-) where the table specifies a priority, but I do think that priority, probably unique in the yang sense, is the way to do it, a bit not being enough to ensure a unique selection. Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From randy_presuhn@mindspring.com Sat Mar 17 10:49:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7C21F85EC for ; Sat, 17 Mar 2012 10:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGx-Pzf+diBZ for ; Sat, 17 Mar 2012 10:49:34 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B47D621F85A2 for ; Sat, 17 Mar 2012 10:49:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ShjBBakdOdJEl01nXJjVuTrqlJlOKf9Hslo5gOZBoJOWfcnG8RlRXwWK8uRQjFag; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.101.141.193] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1S8xkz-0001GD-S1 for netmod@ietf.org; Sat, 17 Mar 2012 12:49:34 -0500 Message-ID: <002a01cd0466$48d7f420$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120313.214540.312716890.mbj@tail-f.com><047b01cd01bf$7e0bdb60$4001a8c0@gateway.2wire.net><20120314.115501.554379227389547490.mbj@tail-f.com><4F60B97F.7080202@netconfcentral.org><20120314155649.GA1206@elstar.local> <014e01cd0432$087873c0$4001a8c0@gateway.2wire.net> Date: Sat, 17 Mar 2012 10:49:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88bd6018022af3585aad05b2107d7619fb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.101.141.193 Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 17:49:35 -0000 Hi - > From: "t.petch" > To: "Juergen Schoenwaelder" ; "Andy Bierman" > Cc: > Sent: Saturday, March 17, 2012 4:35 AM > Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-00 ... > From: "Juergen Schoenwaelder" > To: "Andy Bierman" > Cc: > Sent: Wednesday, March 14, 2012 4:56 PM ... > > That looks a bit too simplistic to me. DHCP is used widely and I would > > be not surprised if for many usages the only config choice is really > > just DHCP on/off for most users. Once we go beyond on/off, I think the > > world is not that simple anymore. And in fact, you configure your DHCP > > client what it requests. How that information is then _used_ if > > provided by the server especially, if it competes with other > > information, is the v6ops problem. So the text would be really "obtain > > xxx information" rather than "use xxx information" (and the proper way > > of modeling is likely to list the DHCP options that are requests or > > provided as hints to the DHCP server, that is it goes beyond a simple > > bits type. > > This is more like what I was thinking of, that there is DHCP configuration/state > but that there is also configuration/state for the protocols for which DHCP > provides raw data. The DHCP module would specify what DHCP options should be > requested and what data came back in response, while the module for the other > protocols would specify the mechanism for selecting between which of several > options should be chosen in order to arrive at a configuration. > > IPv6, in its attempt to be auto-configuring, has created such a situation, with > the prefix, which could come from a router RA (or more than one) or from DHCP > and the WG cannot produce a set of rules which satisfy the varying needs; and > something similar arises with address selection, which of the many possible > source and destination address pairs should be used for a packet. > > The case we already have is the selection of security credentials for SNMP over > TLS, snmpTlstmCertToTSNTable, (not that I expect to see that modelled in yang > any time soon:-) where the table specifies a priority, but I do think that > priority, probably unique in the yang sense, is the way to do it, a bit not > being enough to ensure a unique selection. I think these issues need to be separated. 1) Configuring whether a particular mechanism should try to *obtain* a given piece of configuration information. This seems to be part of the configuration of that mechanism, since it's not necessarily configurable for all mechanism. 2) Configuring whether that configuration information, once obtained by a particular mechanism, should be used. Beyond a simple enable / disable of the use of a particular mechanism, which might be reasonably modeled in the configuration of that mechanism, this is not a binary decision if there is need to support anything more elaborate than (a) or (b) below to select from among the values provided by various sources: a) use only the first mechanism to supply a value (begs the question of what to do if that mechanism later provides another value) b) use the most recent (regardless of source) c) use this source only if a value has not been obtained from a (prioritized) preferred mechanism. (begs the question of what to do if that or a more preferred mechanism later provides another value) Since implementing these policies requires knowledge of all the configuration mechanisms supported by a system, modeling these policies is distinct from the modeling of the individual mechanisms. Randy From j.schoenwaelder@jacobs-university.de Mon Mar 19 03:15:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804B321F864C; Mon, 19 Mar 2012 03:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.211 X-Spam-Level: X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faY4SjOcjEQ7; Mon, 19 Mar 2012 03:15:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0974521F8647; Mon, 19 Mar 2012 03:15:07 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5FA120D0A; Mon, 19 Mar 2012 11:15:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AfP6YxAOSG-W; Mon, 19 Mar 2012 11:15:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7036A20CEE; Mon, 19 Mar 2012 11:15:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 64F491E0CF1A; Mon, 19 Mar 2012 11:15:05 +0100 (CET) Date: Mon, 19 Mar 2012 11:15:05 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org, netmod@ietf.org Message-ID: <20120319101505.GA85201@elstar.local> Mail-Followup-To: netconf@ietf.org, netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 10:15:11 -0000 Hi, a number of NETCONF / YANG contributors plan to meet on Monday morning 09:00-11:30 in order to informally discuss where we are with NETCONF and YANG adoption and if there is any useful work that people find valuable to spent their time on and which might be relevant from an IETF perspective. Some topics that have popped up several times include: - REST interface to NETCONF/YANG - Modeling operational state - XPATH function library for YANG - Issues with the candidate editing model The goal of the meeting is to dive into a certain level of technical depth to better understand the feasibility / complexity of potential solutions. People who like to attend should thus be warned that this meeting is not about high-level lets dream up something in the blue sky discussions. Note that this is an informal meeting. We plan to report in the AOB part of the NETMOD or NETCONF meetings (likely the NETMOD meeting since the NETCONF meeting is rather short). We are trying to find a suitable room. I will post a pointer once we have one. The fallback is to simply meet at the registration area. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Mar 22 03:49:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84C821F868C for ; Thu, 22 Mar 2012 03:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKMvH-BCQsww for ; Thu, 22 Mar 2012 03:49:36 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3051C21F868A for ; Thu, 22 Mar 2012 03:49:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIoDa0/GmAcF/2dsb2JhbABEtzOBB4ILAQEDEh4KUQEVFQYMDAdXAQQbGoVvgXmYFIQbnCONQoI/YwSbbooZgmiBWw X-IronPort-AV: E=Sophos;i="4.73,629,1325480400"; d="scan'208";a="338347405" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Mar 2012 06:49:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Mar 2012 06:41:13 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 11:49:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-netmod-smi-yang-04 Thread-Index: Ac0IGXdEXLRQhoK2Ti236NlBBqWe/g== From: "Romascanu, Dan (Dan)" To: Subject: [netmod] AD review of draft-ietf-netmod-smi-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:49:36 -0000 Please find below the AD review of draft-ietf-netmod-smi-yang-04. The document is in good shape and I am sending it to IETF Last Call. Please consider the comments below together with the other IETF LC comments.=20 Technical comments are marked with a T, Editorial Comments are marked with an E.=20 T1. In Section 2:=20 Implementations are encouraged to provide options to handle situations where DISPLAY-HINTs are added during a revision of a module and backwards compatibility must be preserved. It is not clear how this is realized. How can the possible DISPLAY-HINTs be anticipated, what options could be provided?=20 Also is 'are encouraged' similar to a MAY? The next paragpraph uses a 2119 keyword.=20 T2. In Section 10:=20 extension max-access { argument "access"; description "The max-access statement takes as an argument the MAX-ACCESS assigned to an SMIv2 object definition"; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } However the introduction says This document describes a translation of SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. =20 The statement in the introduction seems contradictory with the description. What happens if the MAX-ACCESS indicates that the object is writeable?=20 Moreover section 11 starts with the statement:=20 The translation of SMIv2 MIB modules into YANG modules defined above is read-only. =20 nnd continues with defining configuration nodes as an exception that needs to be documented.=20 What am I missing? E1. In Section 5.2:=20 The translation of the OwnerString and InterfaceIndex textual conventions of the IF-MIB [RFC2863] are shown below. s/translation/translations/ Regards, Dan From iesg-secretary@ietf.org Thu Mar 22 03:59:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6785321F8621; Thu, 22 Mar 2012 03:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o4FumxoqcJ0; Thu, 22 Mar 2012 03:59:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D23521F85D8; Thu, 22 Mar 2012 03:59:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120322105952.7972.94835.idtracker@ietfa.amsl.com> Date: Thu, 22 Mar 2012 03:59:52 -0700 Cc: netmod@ietf.org Subject: [netmod] Last Call: (Translation of SMIv2 MIB Modules to YANG Modules) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:59:57 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Translation of SMIv2 MIB Modules to YANG Modules' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netmod-smi-yang/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netmod-smi-yang/ballot/ No IPR declarations have been submitted directly on this I-D. From j.schoenwaelder@jacobs-university.de Thu Mar 22 04:26:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8687A21F865C for ; Thu, 22 Mar 2012 04:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrjFuF27totM for ; Thu, 22 Mar 2012 04:26:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 708AC21F8661 for ; Thu, 22 Mar 2012 04:26:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A28820CF7; Thu, 22 Mar 2012 12:26:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BxlLn2nKTBzc; Thu, 22 Mar 2012 12:26:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EB7920CB7; Thu, 22 Mar 2012 12:26:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 26B8F1E17C9B; Thu, 22 Mar 2012 12:26:24 +0100 (CET) Date: Thu, 22 Mar 2012 12:26:24 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120322112624.GB22237@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-smi-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:26:26 -0000 On Thu, Mar 22, 2012 at 11:49:33AM +0100, Romascanu, Dan (Dan) wrote: > Please find below the AD review of draft-ietf-netmod-smi-yang-04. The > document is in good shape and I am sending it to IETF Last Call. Please > consider the comments below together with the other IETF LC comments. Dan, thanks for your review. Let me quickly followup on your technical comments. > Technical comments are marked with a T, Editorial Comments are marked > with an E. > > T1. In Section 2: > > Implementations are encouraged to provide > options to handle situations where DISPLAY-HINTs are added during a > revision of a module and backwards compatibility must be preserved. > > It is not clear how this is realized. How can the possible DISPLAY-HINTs > be anticipated, what options could be provided? > > Also is 'are encouraged' similar to a MAY? The next paragpraph uses a > 2119 keyword. Its about an option that can be used to translate the new module as if the added DISPLAY-HINTs would not be there. I would have to think about better wordings. Something like: smidump -f yang --yang-ignore-display-hint=fooObject FOO-MIB (Not that I have implemented this yet but I probably should.) Since the text talks about implementation specific options that are not part of the translation algorithm itself, I ended up using a phrase like "encouraged". I admit that I am pretty bad in proper RFC 2119 keyword usage. > T2. In Section 10: > > extension max-access { > argument "access"; > description > "The max-access statement takes as an argument the MAX-ACCESS > assigned to an SMIv2 object definition"; > reference > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > } > > However the introduction says > > This document describes a translation of SMIv2 [RFC2578], [RFC2579], > [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only > access to data objects defined in SMIv2 MIB modules via NETCONF. > > The statement in the introduction seems contradictory with the > description. What happens if the MAX-ACCESS indicates that the object is > writeable? The generated YANG module only has "config false" definitions. The smiv2:max-access extension just carries the originial SMIv2 access so that it is not lost - it does not change the fact that the YANG definition is "config false". > Moreover section 11 starts with the statement: > > The translation of SMIv2 MIB modules into YANG modules defined above > is read-only. > > nnd continues with defining configuration nodes as an exception that > needs to be documented. > > What am I missing? Section 11 provides guidance: if an implementation chooses to implement a "config false" YANG object as "config true", then this needs to be properly declared using the YANG deviation mechanism. The YANG module generated by the translation rules remains read-only. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 22 10:38:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7EA21F855D; Thu, 22 Mar 2012 10:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7haUINFPezAc; Thu, 22 Mar 2012 10:38:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8471721F8549; Thu, 22 Mar 2012 10:38:52 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D72020D3B; Thu, 22 Mar 2012 18:38:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9wcGRCPuWtSq; Thu, 22 Mar 2012 18:38:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 067F920D33; Thu, 22 Mar 2012 18:38:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F12F61E185CA; Thu, 22 Mar 2012 18:38:50 +0100 (CET) Date: Thu, 22 Mar 2012 18:38:50 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org, netmod@ietf.org Message-ID: <20120322173850.GC23587@elstar.local> Mail-Followup-To: netconf@ietf.org, netmod@ietf.org References: <20120319101505.GA85201@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120319101505.GA85201@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 17:38:53 -0000 On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, > > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: > > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model > > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. > > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). > > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. The room has been found: Room 237M is available on Monday, 26th (0900-1130). Thanks to Dan for organizing the room. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From james.huy.nguyen@gmail.com Thu Mar 22 11:46:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD4B21F854B; Thu, 22 Mar 2012 11:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZwm089EIiN7; Thu, 22 Mar 2012 11:46:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5932B21F8526; Thu, 22 Mar 2012 11:46:20 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2313577ggm.31 for ; Thu, 22 Mar 2012 11:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YFllUGiWDJXfnTmGc8bOA5tps/0wvhukeZsZF8+v0B4=; b=ZLd0I7Sg+7UHjYajBo7LAHe/KlLqmbJgPxStnPRecciotqKigzq6uEEfKsPAVocl2D iLad4lmmLprzCtCNkI8LjvSV/fQXCOZx/NyiGxf6DJ3XYT1rd1PhrUFnjHIo+RskTZ6q CWJaqfUXHbOsmbBd6S1wP9kKCwGkCMDFxUo5FktQGfwdfS+ehhJqK18XjtgAiHOIDhPr GU5m+JmkaKQRSoqSsaTGQEeWIwxBDERTks8Q+B0W1Q9jmgLaUjfk1+xRUZGS5WbRPknF OypxVL8Gu/Waldux3Vhem8E5P7kzsOV1yQfk0hm3D71GkHKa3oQLNigtBjU8WRICf0+g Yp2g== MIME-Version: 1.0 Received: by 10.236.136.99 with SMTP id v63mr4576254yhi.27.1332441979990; Thu, 22 Mar 2012 11:46:19 -0700 (PDT) Received: by 10.101.112.9 with HTTP; Thu, 22 Mar 2012 11:46:19 -0700 (PDT) In-Reply-To: <20120319101505.GA85201@elstar.local> References: <20120319101505.GA85201@elstar.local> Date: Thu, 22 Mar 2012 14:46:19 -0400 Message-ID: From: James Nguyen To: Juergen Schoenwaelder , netconf@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary=485b397dd125e6b21804bbd9527f Subject: Re: [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:46:21 -0000 --485b397dd125e6b21804bbd9527f Content-Type: text/plain; charset=UTF-8 Hi Juergen, Our team, US Army CERDEC, is currently working on improving NETCONF by adding a common interface on top of it. The current proposal is to use US Naval Research Laboratory (NRL)'s NORM while REST over NETCONF is in discussion. Thus, I'm interested in listening the discussion of REST interface to NETCONF/YANG. Unfortunately, I won't be able to attend the meeting in Paris. Is there a conference bridge and time that I could dial in? Thanks, James On Mon, Mar 19, 2012 at 6:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: > > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model > > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. > > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). > > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- James Nguyen Email: james.huy.nguyen@gmail.com --485b397dd125e6b21804bbd9527f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Juergen,

Our team, US Army CERDEC, is currently worki= ng on improving NETCONF by adding a common interface on top of it. =C2=A0Th= e current proposal is to use US Naval Research Laboratory (NRL)'s NORM = while REST over NETCONF is in discussion. =C2=A0Thus, I'm interested in= listening the discussion of REST interface to NETCONF/YANG. =C2=A0Unfortun= ately, I won't be able to attend the meeting in Paris. =C2=A0Is there a= conference bridge and time that I could dial in?

Thanks,

James

On Mon, Mar 19, 2012 at 6:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

a number of NETCONF / YANG contributors plan to meet on Monday morning
09:00-11:30 in order to informally discuss where we are with NETCONF
and YANG adoption and if there is any useful work that people find
valuable to spent their time on and which might be relevant from an
IETF perspective. Some topics that have popped up several times
include:

- REST interface to NETCONF/YANG
- Modeling operational state
- XPATH function library for YANG
- Issues with the candidate editing model

The goal of the meeting is to dive into a certain level of technical
depth to better understand the feasibility / complexity of potential
solutions. People who like to attend should thus be warned that this
meeting is not about high-level lets dream up something in the blue
sky discussions.

Note that this is an informal meeting. We plan to report in the AOB
part of the NETMOD or NETCONF meetings (likely the NETMOD meeting
since the NETCONF meeting is rather short).

We are trying to find a suitable room. I will post a pointer once we
have one. The fallback is to simply meet at the registration area.

/js

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49= 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, = Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/= >
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod



-- James Nguyen
Email: jame= s.huy.nguyen@gmail.com
--485b397dd125e6b21804bbd9527f-- From mbj@tail-f.com Fri Mar 23 07:29:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD47321F84AA for ; Fri, 23 Mar 2012 07:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxlmhEcIMJ8W for ; Fri, 23 Mar 2012 07:29:06 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 36EC921F850F for ; Fri, 23 Mar 2012 07:29:06 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6F99C12008F7 for ; Fri, 23 Mar 2012 15:29:04 +0100 (CET) Date: Fri, 23 Mar 2012 15:29:03 +0100 (CET) Message-Id: <20120323.152903.170594107366638402.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:29:07 -0000 Hi, Here's a list of the open issues I will present in our session next week. It is really just a summary of issues raised on the ML. * ip-07 add parameters to control is-router / ip-forwarding [open] RFC 4861 mandates a per-interface config parameter IsRouter. IP-MIB defines this as ipv6InterfaceForwarding, but also has a global parameter ipv6IpForwarding, that can be used to globally disable forwarding on all interfaces. Q1. Should we add a per-interface is-router / ip-forwarding leaf? Q2. Should we also add the global parameter? Q3. Should we do the same for ipv4? IP-MIB doesn't have per-interface forwarding for ipv4. Linux supports per-interface forwarding. ** Solution #ip-07.01 Yes to all. If create-global-addresses is kept, it can be conditional with a "when" expression based on this new leaf: leaf is-router { // or ip-forwarding? type boolean; description "If true, the device acts as a router, otherwise as a host."; } leaf create-global-addresses { when "../is-router = 'false'"; ... } * ip-08 configure dynamic mechanisms for ip address assigments [open] IP addresses can be assigned using different mechanisms; manually configured (as specified in the current datamodel), or assigned through some dynamic protocol like DHCP. It is agreed that we should not add parameters to configure these other protocols, but it might be useful to have a standard way to control which mechanisms to use for address assignment. ** Solution #ip-08.01 Something like this: container ipv6 { ... leaf-list address-assignment { type enumeration { enum manual; // needed; or always added? enum dhcp; enum no-autoconf; // autoconf is enabled by default } } ... } If this is done, this replaces the create-global-addresses leaf. ** Solution #ip-08.02 This could also be more extensible by using an identity: container ipv6 { ... leaf-list address-assignment { type identityref { base ipv6-address-assignment-mechanism; } } } And then in the dhcp module: identity dhcp { base ip:ipv6-address-assignment-mechanism; } ** Solution #ip-08.03 No need for these fancy mechanisms in this simple case; addresses are additive, just use the addresses from all enabled mechanisms. * ip-09 add non-config leafs [open] It was suggested that we add the following stats objects: o all addresses on an interface (configured or dynamically assigned) o RFC 4861, 6.3.2 (per interface) - link-mtu - cur-hop-limit - base-reachable-time - reachable-time - retrans-timer o RFC 4861, 5.1 (global) - neighbor cache - routing table Ditto for ipv4. Should we add stats objects at all? What about duplication of MIB objects, is that a problem? If we add all addresses on an interface, do we also need a list of all interfaces, including the non-configured interfaces? /martin From lhotka@nic.cz Fri Mar 23 08:07:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08521F8597 for ; Fri, 23 Mar 2012 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmIrfc-bqAiU for ; Fri, 23 Mar 2012 08:07:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1DC21F8594 for ; Fri, 23 Mar 2012 08:07:44 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 7C5382A26F2 for ; Fri, 23 Mar 2012 16:07:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1332515261; bh=cFOyYJ/ljiDEJVbDsL5LrOuXj95ZYBtokwbT5AG0ElY=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=eCHKJLKedadIeIvHU6m/CwLWkZVr4Bev1EnpuhIle+9oO42Sib/7l9QagWPe2kM7k hskEUOnz6fRBr9yrT+Uk98CKydFUwTTZJHHBwFh7LcSnBI9Ih/RoaaJ3E/TITLDUi6 HrTUdIyhFH+W5aYoTncHHSHnxWc9W3QV+h/KaVTo= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Mar 2012 16:07:41 +0100 Message-Id: To: netmod@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] routing-cfg issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:07:49 -0000 Hi, I have so far identified the following two open issues related to the = core routing modules: 1. Distribution of interface configuration parameters and state data = between /if:interfaces and /rt:routing/rt:router/rt:interfaces trees - = and, in particular, the is-router flag (cf. Martin's issue ip-07/Q1). 2. Clarification of the unique statement - agree on either the stricter = or more liberal version. I have just received two external reviews, I will try to process them = before the meeting, they may result in new issues. Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Fri Mar 23 12:39:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A2F21F842F; Fri, 23 Mar 2012 12:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffhb1ypVaGpo; Fri, 23 Mar 2012 12:39:08 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4373A21F8460; Fri, 23 Mar 2012 12:39:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D75CC5401AE; Fri, 23 Mar 2012 20:39:04 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miL1-ZmQTuUk; Fri, 23 Mar 2012 20:38:59 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C9A2C540159; Fri, 23 Mar 2012 20:38:59 +0100 (CET) From: Ladislav Lhotka To: thomas.morin@orange.com, rtg-ads@tools.ietf.org In-Reply-To: References: User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Hi Thomas, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii thanks a lot for your review, I find you comments very helpful. Please see my responses inline (I am also cc-ing it to the NETMOD mailing list). Mail-Followup-To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org Date: Fri, 23 Mar 2012 20:38:16 +0100 Message-ID: Cc: draft-ietf-netmod-routing-cfg.all@tools.ietf.org, rtg-dir@ietf.org, netmod@ietf.org Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 19:39:12 -0000 On Fri, 23 Mar 2012 12:04:10 +0100, wrote: > Hello, > > I have been selected as Routing Directorate reviewer for an early review of this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. This particular case is an early review requested by Routing ADs, with the goal of assessing the relevance of the work and eventually provide guidance. > > > Although these comments are primarily for the use of the Routing ADs, it can be helpful if you consider them along with any other comments that you receive. > > For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Document: draft-ietf-netmod-routing-cfg-02 > Reviewer: Thomas Morin > Review Date: 2012-03-22 > Intended Status: Standards Track > > > Summary: > > My overall impression of this document is rather positive, it seem to me as providing a good starting point for covering routing tables and routing protocols in netmod. > > However, I think there is possibly some room for improvement for making this base Yang routing module generic enough to really be applicable to all routing protocols and use cases. See below for more specific questions/suggestions, generic or related to specific protocols or use cases (ECMP support, multicast, MPLS/BGP VPNs, etc.). > This is quite possible, I only dared to address areas I am reasonably familiar with, which is essentially standard IP routing and some MPLS. > > It is also important to note that the usefulness of these specs is conditioned (a) by the development of Yang modules for each relevant routing protocol (which should be fairly doable assuming this base module is generic enough) and (b) conditioned by the development of additional Yang modules allowing the description of non-trivial import/export filters between routing protocols and routing tables (this part being possibly harder to achieve, since it means finding a common language able to express the variety of ACLs/policies that can be expressed on different router OSes today). > Absolutely. This is a usual dilemma: we can either try to develop a full-fledged route filtering framework and expect/force everybody to use it, or open the space for multiple competing frameworks. The draft and the routing module take the latter approach, because the logics of existing implementations differ from each other considerably, so it is not very likely to find their common denominator. I plan to implement the route filtering framework of the BIRD routing daemon which it is maintained by my company. > > Comments: > > --- Note Well ... > > I'm hoping this review will be relevant and useful. But, keeping in mind that doing this review was my first exposure at Yang, some comments I'm making could possibly be completely off track, and what I think I understood could as well be, partly or fully, wrong. If/when this happens to be the case, I apologize; just be frank and honest and eventually tell me to go back home and read a few other specs before I come back... ;-) No, I don't think it is necessary. :^) Andy Bierman once described the problem we are facing here: "The domain experts don't really know the data modeling stuff, and the data modeling experts don't really know the domain stuff." I certainly hope we can obtain sound results through cooperation between both classes of experts. > > There was one specific difficulty for doing this review: for someone lacking XPath fluency, it is hard to understand some details of the Yand modules. For instance, there is a complex condition for routing-protocol/connected-routing-tables, and it would have remained totally obscure to me without the error-message that is also provided ; the corresponding constraint was also explained in the Intro of section 4, so this particular case was ok (see more precise comment below). Beyond this example, the real issue is that I can't know if there is any other similar XPath constraint or other detail that I might have missed. > RFC 6087 requires all Standards Track modules to describe the purpose of all 'must' statements in 'description'. Actually, such a description often seems superfluous if there is an 'error-message' statement. At any rate, the purpose of such statement should be reasonably clear even without deciphering the XPath expressions. Please let me know if it is not the case and I will try to improve the descriptions and/or error messages. > > -- Document organization > > The interface parameters for IPv6 Neighbor Discovery would I think deserve being moved in a companion Yang module, unless there is a strong reason (such as a dependency) why it would be needed to be kept here. Other IPv6 ND parameters are defined by the "ietf-ip" module. It may indeed be worth reconsidering the structure of the "core" modules. > > > --- Extensibility > > It seems to me that these specs where written with extensibility in mind, which is a very positive point. One routing protocol example is given (RIP), but the structure is supposedly applicable to other routing protocols. You will find below a few questions related to the genericness, in fact mostly cases that may show that the current specs may not be generic enough with suggestions on possible fixes. > > > --- Completeness > > One question is how these Yang modules can be used today. It is clear that without companion specs for specific protocols and filters, not very much can be done with it (merely static routing with only trivial accept-all / deny-all filters). It is perfectly acknowledged in the document. One part that may prove hard to achieve is the unification of the variety of ACL/policies existing on different routing equipment vendors OSes, into one common Yang language for routing filters. Right. When we were preparing the current NETMOD charter, I actually proposed to include a route filtering framework but the WG consensus then was not to do so. As a proof of concept covering both routing protocols and route filtering, I will try to develop a complete data model for BIRD. > > > --- Information on routes > > The Yang module let's the operator read the routing tables. It looks like a very valid and useful thing (and not new, see RFC1213 MIB). > > However, I'm wondering about the following points: > > - usually, a routing table may have multiple routes for a said destination address, some being possibly less specific than others, or inactive due to various reasons : it did not identify how these specification allow the operator to see all routes of a routing table for a said prefix, or all the most specific routes including the inactive ones, or all the most specific actives routes when there is more than one (required I think for ECMP support), etc. ? it seems it would be worth to extend the get-route RPC to allow expressing all these kind of questions The 'get-route' method doesn't try to be terribly general or extensible, it is mainly intended as a reminder to routing experts that YANG also allows for defining new RPC methods. I think it will be easier to decide what methods are needed as soon as there are data models for the major routing protocols, such as OSPF or BGP. > > - when dumping a full routing table, will this be efficient ? wouldn't it be more efficient to rely on other dedicated mechanism already used today to get knowledge of a routing protocol (e.g. BCP or Route Reflection for BGP, or IGP tapping techniques for IGPs) RPC methods doing such things should be defined as a part of data models for routing protocols. With a route filtering framework, one could also set up an extra routing table and feed it with an appropriately filtered selection of routes. > > - assuming that in some cases dumping whole routing tables would not be efficient, will there be an efficient way to get aggregate information on a routing table ; such as "how many routes in the routing table" ? or "how many inactive routes in the routing table" ? "how many routes for prefix x.y.z" ? Yup, this sounds like a useful thing to have. Perhaps it might make sense to also have a generic RPC returning the number of entries in a list or leaf-list. > > - the term "destination-address" chosen to designate the piece of information based on which the get-route RPC works, is possibly not suitable for all routing protocols. The examples that I would see are (a) MP-BGP, where the routing information (NLRI) can be mostly anything (depends on the SAFI), and (b) multicast, where the routing information on which the PIM protocols work can be a (source,group) tuple, possibly augmented with flags Yes, see above. Do you have an idea how to define a general method without having the data models for MP-BGP or multicast routing? > > - (related to the previous point:) : I'm unclear if these specs allow a get-route to match on different portions or attributes of a routes (eg. get route for prefix X advertised by peer X, or having been readvertised by AS Y...)... As I understand, there can be some AFN/SAFI specific extensions, but no per-protocol extensions. Is this a correct understanding ? If not, wouldn't it make sense to make it more extensible ? There can be per-protocol extensions, too, it is also demonstrated in the RIP example. > > - why restrict the get-route RPC to only query the special/default "FIB" routing table ? it would seem useful to be able to query any routing table. This could be done but it would bring new issues to consider - multiple candidate routes etc. The 'get-route' method is supposed to answer the simple question: "Which route will be used for forwarding packets to destination W.X.Y.Z?" > > > > --- Redistributing routes directly between routing protocols > > These specifications only allow the exchange of routes from a routing protocol or routing table to a routing table, but not from a routing protocol to another routing protocols. However, the latter is something used a lot in practice (e.g. controlling redistribution between two IGP areas). Of course, by using an intermediate routing table you could achieve the same result, but doesn't it look like extra overhead ? Some implementations (IOS, for example) redistribute routes between protocols while others (JUNOS, BIRD) use an intermediate routing table. But as you say, the former approach may be emulated with the latter. In the most typical case when two protocols are connected to the same (e.g. main) routing table, each protocol can use a filter to pull the routes originating from the other protocol. > > > --- Modify routes being redistributed > > There does not seem to be any way through which a route may be modified/augmented by a filter when exported from a routing table or protocol to another. It seems to me that this is something that is used a lot in practice. Of course, this is just another task for the future route filtering framework(s). > > > --- Multiple routing instances > > The specs are written so as to allow multiple "routers" to co-exist on an equipment in isolation, which looks very useful. However, I'm wondering if such an ability is specific to "routing", or if it shouldn't be part of a more generic Yang module, so as to reuse the same sub-router hierarchy for routing and other Yang modules. OK, so you mean virtualization of the entire device, be it a router or anything else. AFAIK, this hasn't been discussed by the WG yet. > > > --- Applicability to RFC4364 > > Allowing multiple "routers" is a good starting point for using these specs in the context of RFC4364 (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the way the filters are defined would not work in the context of RFC4364, where a BGP routing instance in the master "router" exports selected routes in each of the routing table of each VPN (VRF). The VRF also export routes to the master instance. The draft says: "Although it it not enforced by the data model, different router instances normally do not internally share any data." So this may be a use case for sharing data among different router instances. There is nothing in the data model (or YANG) preventing this. I will also relax the cited sentence, in the following sense: "Implementations may specify the rules for sharing data among router instances." > > The two obstacles I would see (I might be wrong) are the following: > - no way to modify routes while they are imported/exported : the RFC4364 use-case would require the ability to (at least) add/strip attributes to/from the routes Each import/export is subject to a route filter, which should be able to perform such manipulations. > - no way to redistribute routes between routing tables of different "routers" (what let me think this constraint exists is (a) the inability to name a router when designating a routing-table to import/export from/to, and (b) the XPaths for connected-routing-tables/routing-table/name and recipient-routing-tables recipient-name, which seems to not be able to point higher in the hierarchy than the 'router' on which they are defined ) True, the connected routing table currently must be within the same router instance. So this constraint should be removed, and implementations that need such an isolation will have to state it explicitly. > - the constraint that for a said routing protocols "For each AFN/SAFI pair there may be at most one connected routing table." . In the RFC4364 case, the global BGP routing process would push routes to multiple VRFs. This is most likely not a problem because any number of recipient routing tables can be configured to receive (filtered) routes from the single routing table which is connected to a routing protocol, cf. the "recipient-routing-tables" list. > > > --- Enabling/disabling an interface > > Something done very often on a router consists in putting an interface "shutdown" or "inactive", preserving its configuration but making it ignored by the router and keeping the link down. These specifications don't seem to provide this. Is this something already, or expected to be, provided by another Yang extension ? The "ietf-interfaces" module has this "enabled" switch, that will server this purpose. We are also discussing where to put the "is-router" toggle that enables/disables forwarding on an interface. > > If so, how would the two interact, if for instance, an interface is shutdown in this other module but used in the routing module ? Good point, this has to be specified in the draft. > > > --- Enabling/Disabling a protocol on an interface, or modifying protocol per-interface parameters > > Something done very often on a router consists in enabling/disabling a said protocol on a said interface, or more generally modifying parameters for a said protocol on a said interface (typical example being the metric). As I understand this would be allowed by these specs by having a module extending protocol X augment routing/router/interface with its own parameters. However, I'm wondering if these per-protocol per-interface parameters wouldn't be better placed under each routing/router/routing-protocol[X]. It is up to the designer of the protocol data model, both options are possible. Maybe we should give some guidelines. > > The reasons I see are the following: > * in some cases a said router may run multiple instances of a said protocol type, in parallel, and you may need to have a way to differentiate enabling instance A of protocol X from instance B of protocol X > * you could even find use cases where a multiple instances of a said protocol type run in parallel on a said interface (eg. multi instance ISIS) > * my understanding of the Yang module is that the current structure would not allow augmenting a said interface multiple times for a same parameter of a said protocol type. If something like this is necessary, one can augment an interface configuration with a list where each entry corresponds to one instance of the routing protocol. > > > --- Editorial aspects... > > Although it's not the primary purpose of this review, I have to mention that the editorial quality of the document is excellent ; I have particularly appreciated the HTML-rendered version produced by the XML RFC editing toolchain. Thank you. Best regards, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Mar 23 13:41:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9121F858B for ; Fri, 23 Mar 2012 13:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYqe0JSshSdo for ; Fri, 23 Mar 2012 13:41:00 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4573621F8550 for ; Fri, 23 Mar 2012 13:41:00 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BEAAD1200D2E; Fri, 23 Mar 2012 21:40:58 +0100 (CET) Date: Fri, 23 Mar 2012 21:40:58 +0100 (CET) Message-Id: <20120323.214058.231528491.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] LL review of ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:41:01 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > this is my review od the ip-cfg-02 draft module. Some of the issues have > already been discussed. > > *** Proposed changes > 1. (ad issue #ip-02.02) Change "ipv4" and "ipv6" nodes into > presence containers but keep the "enabled" knob. > > In the current version, IPv6 is enabled on an interface even if > the "ipv6" container is not present and there is no other > mention about IPv6. If "ipv6" becomes a presence container, > three states of the configuration are possible: > - no IPv6 configuration is present => IPv6 is disabled > - IPv6 configuration is present but IPv6 disabled via > enabled=false. > - IPv6 configuration is present and IPv6 enabled. It seems you want ipv6 to be disabled, unless the operator explicitly says so. If so, why not simply make "enabled" false by default? Having two mechanism (enabled and P-container) seems redundant. > 2. Put the "address" list into a container, e.g. "addresses". > > Reason: avoid interleaving the addresses with other nodes, e.g. >
...
> ... >
...
I'd rather not invent artificial nodes in order to tweak the XML encoding... if this is a real problem, we should consider changing the encoding rules in 6020. > 3. Add boolean leaf "is-router" (or "ip-forwarding") under both > "ipv4" and "ipv6". Ok, this makes sense. I have added this as an issue to discuss. > For IPv6, this configuration variable is required by RFC 4861, > sec. 6.2.1 and IMO belongs to this module. The other > router-specific configuration variables from that section are > defined in the 'routing-cfg' module. > > The leaf "create-global-addresses" then should have a dynamic > default equal to not(is-router). > > 4. Add a config=false list of all addresses on an interface > (manually or automatically configured). > > 5. Add the variables required by RFC 4861, sec. 6.3.2 (config=false > for all): > - link-mtu > - cur-hop-limit > - base-reachable-time > - reachable-time > - retrans-timer > > 6. Add the following global (i.e. not per-interface) config=false > structures as required by RFC 4861, sec. 5.1.: > - neighbour cache > - routing table > > Do the same also for IPv4. For all these, see my open issue ip-09. The first question is if we should add read-only objects already defined in the corresponding MIB or not. > *** Formal > > - p. 4: s/familiy/family/ Fixed. /martin From lhotka@nic.cz Sat Mar 24 02:08:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2039A21F845B for ; Sat, 24 Mar 2012 02:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HaNgGC0qcSl for ; Sat, 24 Mar 2012 02:08:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1E25921F8458 for ; Sat, 24 Mar 2012 02:08:54 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id EBCFD2A27C8; Sat, 24 Mar 2012 10:08:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1332580133; bh=iA74l4Cuc6SK19DjqvF2Q4ZxVif72x3A09iRs7+yjNI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c9YfhQvtufhNpFod+r3t7ZN2LOHvA5YXibHNdrn8ff5SNW5WhQenpRTD3nUh18zWq Beb8YPryAAjyViod2VPc6w3BvgTqANyEOosata+FcRLGuGvEiMUAXOhO4WkXlvtVFe qolETkt4uFJGtzWjlYZwjffjuIOD5q3aT4RnsafI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120323.214058.231528491.mbj@tail-f.com> Date: Sat, 24 Mar 2012 10:08:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120323.214058.231528491.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] LL review of ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 09:08:56 -0000 On Mar 23, 2012, at 9:40 PM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> this is my review od the ip-cfg-02 draft module. Some of the issues = have >> already been discussed. >>=20 >> *** Proposed changes >> 1. (ad issue #ip-02.02) Change "ipv4" and "ipv6" nodes into >> presence containers but keep the "enabled" knob. >>=20 >> In the current version, IPv6 is enabled on an interface even if >> the "ipv6" container is not present and there is no other >> mention about IPv6. If "ipv6" becomes a presence container, >> three states of the configuration are possible: >> - no IPv6 configuration is present =3D> IPv6 is disabled >> - IPv6 configuration is present but IPv6 disabled via >> enabled=3Dfalse. >> - IPv6 configuration is present and IPv6 enabled. >=20 > It seems you want ipv6 to be disabled, unless the operator explicitly > says so. If so, why not simply make "enabled" false by default? But then you also have the "autoconf/create-global-addresses" toggle. = Its default value is also "true" but it should not apply if IPv6 is not = enabled on the interface. > Having two mechanism (enabled and P-container) seems redundant. Actually, the very notion of P-container seems redundant as nobody is = using it. >=20 >> 2. Put the "address" list into a container, e.g. "addresses". >>=20 >> Reason: avoid interleaving the addresses with other nodes, e.g. >>
...
>> ... >>
...
>=20 > I'd rather not invent artificial nodes in order to tweak the XML > encoding... if this is a real problem, we should consider changing the > encoding rules in 6020. It's not a real problem, just a matter of style. I am using such extra = containers for almost all lists in the routing modules. Both approaches = have their pros and cons, but we should probably unify the style for the = core modules. >=20 >> 3. Add boolean leaf "is-router" (or "ip-forwarding") under both >> "ipv4" and "ipv6". >=20 > Ok, this makes sense. I have added this as an issue to discuss. >=20 >> For IPv6, this configuration variable is required by RFC 4861, >> sec. 6.2.1 and IMO belongs to this module. The other >> router-specific configuration variables from that section are >> defined in the 'routing-cfg' module. >>=20 >> The leaf "create-global-addresses" then should have a dynamic >> default equal to not(is-router). >>=20 >> 4. Add a config=3Dfalse list of all addresses on an interface >> (manually or automatically configured). >>=20 >> 5. Add the variables required by RFC 4861, sec. 6.3.2 (config=3Dfalse= >> for all): >> - link-mtu >> - cur-hop-limit >> - base-reachable-time >> - reachable-time >> - retrans-timer >>=20 >> 6. Add the following global (i.e. not per-interface) config=3Dfalse >> structures as required by RFC 4861, sec. 5.1.: >> - neighbour cache >> - routing table >>=20 >> Do the same also for IPv4. >=20 > For all these, see my open issue ip-09. The first question is if we > should add read-only objects already defined in the corresponding MIB > or not. If not, could such read-only objects be referred to from configuration? Lada >=20 >> *** Formal >>=20 >> - p. 4: s/familiy/family/ >=20 > Fixed. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Sat Mar 24 08:39:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D7A21F86E8 for ; Sat, 24 Mar 2012 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfc2bhxYaevJ for ; Sat, 24 Mar 2012 08:39:33 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C4C3821F86DB for ; Sat, 24 Mar 2012 08:39:32 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A22B61200AE5; Sat, 24 Mar 2012 16:39:30 +0100 (CET) Date: Sat, 24 Mar 2012 16:39:28 +0100 (CET) Message-Id: <20120324.163928.456503641.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120323.214058.231528491.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] LL review of ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 15:39:34 -0000 Ladislav Lhotka wrote: > > On Mar 23, 2012, at 9:40 PM, Martin Bjorklund wrote: > > > Hi, > > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> this is my review od the ip-cfg-02 draft module. Some of the issues have > >> already been discussed. > >> > >> *** Proposed changes > >> 1. (ad issue #ip-02.02) Change "ipv4" and "ipv6" nodes into > >> presence containers but keep the "enabled" knob. > >> > >> In the current version, IPv6 is enabled on an interface even if > >> the "ipv6" container is not present and there is no other > >> mention about IPv6. If "ipv6" becomes a presence container, > >> three states of the configuration are possible: > >> - no IPv6 configuration is present => IPv6 is disabled > >> - IPv6 configuration is present but IPv6 disabled via > >> enabled=false. > >> - IPv6 configuration is present and IPv6 enabled. > > > > It seems you want ipv6 to be disabled, unless the operator explicitly > > says so. If so, why not simply make "enabled" false by default? > > But then you also have the "autoconf/create-global-addresses" toggle. Its > default value is also "true" but it should not apply if IPv6 is not enabled on > the interface. Sure. But that needs needs to be clarified also in the solution proposed by you, right? > > Having two mechanism (enabled and P-container) seems redundant. > > Actually, the very notion of P-container seems redundant as nobody is using it. We use it in snmp-cfg in a few places. I think it has its merits in certain cases. > >> 2. Put the "address" list into a container, e.g. "addresses". > >> > >> Reason: avoid interleaving the addresses with other nodes, e.g. > >>
...
> >> ... > >>
...
> > > > I'd rather not invent artificial nodes in order to tweak the XML > > encoding... if this is a real problem, we should consider changing the > > encoding rules in 6020. > > It's not a real problem, just a matter of style. I am using such extra > containers for almost all lists in the routing modules. Both approaches have > their pros and cons, but we should probably unify the style for the core > modules. > > > > >> 3. Add boolean leaf "is-router" (or "ip-forwarding") under both > >> "ipv4" and "ipv6". > > > > Ok, this makes sense. I have added this as an issue to discuss. > > > >> For IPv6, this configuration variable is required by RFC 4861, > >> sec. 6.2.1 and IMO belongs to this module. The other > >> router-specific configuration variables from that section are > >> defined in the 'routing-cfg' module. > >> > >> The leaf "create-global-addresses" then should have a dynamic > >> default equal to not(is-router). > >> > >> 4. Add a config=false list of all addresses on an interface > >> (manually or automatically configured). > >> > >> 5. Add the variables required by RFC 4861, sec. 6.3.2 (config=false > >> for all): > >> - link-mtu > >> - cur-hop-limit > >> - base-reachable-time > >> - reachable-time > >> - retrans-timer > >> > >> 6. Add the following global (i.e. not per-interface) config=false > >> structures as required by RFC 4861, sec. 5.1.: > >> - neighbour cache > >> - routing table > >> > >> Do the same also for IPv4. > > > > For all these, see my open issue ip-09. The first question is if we > > should add read-only objects already defined in the corresponding MIB > > or not. > > If not, could such read-only objects be referred to from configuration? non-config objects can never be referred to by configuration (leafrefs and i-i). /martin From lhotka@nic.cz Sat Mar 24 09:28:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9563521F85F0 for ; Sat, 24 Mar 2012 09:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsGWTNfQzXN8 for ; Sat, 24 Mar 2012 09:28:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D415221F85ED for ; Sat, 24 Mar 2012 09:28:06 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 65A3D2A2BD6; Sat, 24 Mar 2012 17:28:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1332606485; bh=vSGe770mWFK8nP3Bhl/VWJOYOw58xmCjMGVNpYapp+k=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Da8Rx9C8HhDiLHEB84vq49ZAg9g579lNRgoB5Styw9xfKYUfgll2n5hsR3YshIazM lfKVBdsilueFjLs1uHX9sYqnjzTrH82fzORZDQbzbLvJtH68oLGeBBTnNvAHLSptKA Avhf8bXNQ8dXzpnGJ/bZmhUO1qp+aMBojTlSRKUQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120324.163928.456503641.mbj@tail-f.com> Date: Sat, 24 Mar 2012 17:28:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E937CAD-A78D-4103-97AA-03C3B43A622C@nic.cz> References: <20120323.214058.231528491.mbj@tail-f.com> <20120324.163928.456503641.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] LL review of ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:28:07 -0000 On Mar 24, 2012, at 4:39 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Mar 23, 2012, at 9:40 PM, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> this is my review od the ip-cfg-02 draft module. Some of the issues = have >>>> already been discussed. >>>>=20 >>>> *** Proposed changes >>>> 1. (ad issue #ip-02.02) Change "ipv4" and "ipv6" nodes into >>>> presence containers but keep the "enabled" knob. >>>>=20 >>>> In the current version, IPv6 is enabled on an interface even if >>>> the "ipv6" container is not present and there is no other >>>> mention about IPv6. If "ipv6" becomes a presence container, >>>> three states of the configuration are possible: >>>> - no IPv6 configuration is present =3D> IPv6 is disabled >>>> - IPv6 configuration is present but IPv6 disabled via >>>> enabled=3Dfalse. >>>> - IPv6 configuration is present and IPv6 enabled. >>>=20 >>> It seems you want ipv6 to be disabled, unless the operator = explicitly >>> says so. If so, why not simply make "enabled" false by default? >>=20 >> But then you also have the "autoconf/create-global-addresses" toggle. = Its >> default value is also "true" but it should not apply if IPv6 is not = enabled on >> the interface. >=20 > Sure. But that needs needs to be clarified also in the solution > proposed by you, right? Yes, but my point is that with "ipv6" being a P-container, there are the = three different options above. As long as the operator doesn't create = the container, he needn't bother about IPv6, its default values etc. - = IPv6 simply doesn't exist on that interface. This is the principle of = least embarrassment. ... >>=20 >> If not, could such read-only objects be referred to from = configuration? >=20 > non-config objects can never be referred to by configuration (leafrefs > and i-i). Oh well, I forgot. This is however quite limiting. For example, an IP = address might be configured to serve a certain purpose (as the source = address for a routing protocol, say) with the restriction that it must = be an address that exists on the device - but this may potentially also = include *autoconfigured* addresses which are not present in = configuration data. So this semantic constraint cannot be expressed in = the data model, right? Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Sat Mar 24 13:48:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65DE21F849D for ; Sat, 24 Mar 2012 13:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6A9Rc9SVmnL for ; Sat, 24 Mar 2012 13:48:46 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF7E21F84F1 for ; Sat, 24 Mar 2012 13:48:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT24zJ1X3+XyojAOat/HE2ORMX1Cuz0kc@postini.com; Sat, 24 Mar 2012 13:48:46 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 24 Mar 2012 13:48:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q2OKmT121685; Sat, 24 Mar 2012 13:48:29 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q2OKmdXq076776; Sat, 24 Mar 2012 16:48:39 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201203242048.q2OKmdXq076776@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120323.214058.231528491.mbj@tail-f.com> Date: Sat, 24 Mar 2012 16:48:39 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] LL review of ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 20:48:46 -0000 Martin Bjorklund writes: >It seems you want ipv6 to be disabled, unless the operator explicitly >says so. If so, why not simply make "enabled" false by default? >Having two mechanism (enabled and P-container) seems redundant. As a modeler, I encourage you _not_ to use the tags to turn features off. We did this early in JUNOS and it was painful, since the model has to explicitly allow enable/disable values and they are never in the right spots for the customer's needs. Instead consider something like the JUNOS "inactive" which can be be applied anywhere in the configuration (as a generic mechanism), is completely flexible, and requires no work from the modeler. http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/junos-software-configuration-statements-identifiers-deactivating-reactivating.html >I'd rather not invent artificial nodes in order to tweak the XML >encoding... if this is a real problem, we should consider changing the >encoding rules in 6020. I'm assuming you are not really serious here. >> 3. Add boolean leaf "is-router" (or "ip-forwarding") under both >> "ipv4" and "ipv6". > >Ok, this makes sense. I have added this as an issue to discuss. Are you talking about a knob to indicate the role of the device? What around multi-purpose devices? >> 5. Add the variables required by RFC 4861, sec. 6.3.2 (config=false >> for all): >> - link-mtu >> - cur-hop-limit >> - base-reachable-time >> - reachable-time >> - retrans-timer I would suggest using full words ("current", "retransmit"). Otherwise every modeler will roll their own abbreviation. Or worse, you end up with semi-official abbreviations. >> 6. Add the following global (i.e. not per-interface) config=false >> structures as required by RFC 4861, sec. 5.1.: >> - neighbour cache >> - routing table Are we reimplementing MIBs? Thanks, Phil From mbj@tail-f.com Sat Mar 24 14:07:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954BA21E8018 for ; Sat, 24 Mar 2012 14:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGZCEy442l+h for ; Sat, 24 Mar 2012 14:07:45 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EE78321E800E for ; Sat, 24 Mar 2012 14:07:44 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 65E791200D00; Sat, 24 Mar 2012 22:07:43 +0100 (CET) Date: Sat, 24 Mar 2012 22:07:43 +0100 (CET) Message-Id: <20120324.220743.324080950.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201203242048.q2OKmdXq076776@idle.juniper.net> References: <20120323.214058.231528491.mbj@tail-f.com> <201203242048.q2OKmdXq076776@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] LL review of ip-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:07:45 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >It seems you want ipv6 to be disabled, unless the operator explicitly > >says so. If so, why not simply make "enabled" false by default? > >Having two mechanism (enabled and P-container) seems redundant. > > As a modeler, I encourage you _not_ to use the tags to > turn features off. We did this early in JUNOS and it was painful, > since the model has to explicitly allow enable/disable values and > they are never in the right spots for the customer's needs. > > Instead consider something like the JUNOS "inactive" which can be > be applied anywhere in the configuration (as a generic mechanism), > is completely flexible, and requires no work from the modeler. I absolutely agree with this. I do not like putting meta-data leafs likte "enable" among the data nodes. FWIW, our implementation also supports something like the "inactive" mechansim. (another similar meta-data thing is "comment" or "annotation", which sometimes show up among data nodes as a "description" leaf). However, as it currently stands, there is no standard "inactive" mechanism. Thus, we have to resort to "enable" leafs. The alternative would be to stall the development of data models and work on an "inactive" feature. I don't think this is optimal or realistic. > >I'd rather not invent artificial nodes in order to tweak the XML > >encoding... if this is a real problem, we should consider changing the > >encoding rules in 6020. > > I'm assuming you are not really serious here. The text is in 7.8.5 of 6020: The XML elements representing list entries MAY be interleaved with other sibling elements, unless the list defines RPC input or output parameters. Note that the precondition to my statement is *if* this is a real problem. I don't think it is. > >> 3. Add boolean leaf "is-router" (or "ip-forwarding") under both > >> "ipv4" and "ipv6". > > > >Ok, this makes sense. I have added this as an issue to discuss. > > Are you talking about a knob to indicate the role of the device? > What around multi-purpose devices? I think we need this per interface. See issue ip-07 in my earlier email. > >> 5. Add the variables required by RFC 4861, sec. 6.3.2 (config=false > >> for all): > >> - link-mtu > >> - cur-hop-limit > >> - base-reachable-time > >> - reachable-time > >> - retrans-timer > > I would suggest using full words ("current", "retransmit"). Otherwise > every modeler will roll their own abbreviation. Or worse, you end > up with semi-official abbreviations. > > >> 6. Add the following global (i.e. not per-interface) config=false > >> structures as required by RFC 4861, sec. 5.1.: > >> - neighbour cache > >> - routing table > > Are we reimplementing MIBs? That's the question... When should we write config false data models? Do we recommend people to use SNMP/MIBs for stats only and NETCONF/YANG for config only? If so, we need to be very clear about how to map between these two worlds. /martin From j.schoenwaelder@jacobs-university.de Mon Mar 26 02:56:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D274C21F858A for ; Mon, 26 Mar 2012 02:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rz3dgt0wTqs for ; Mon, 26 Mar 2012 02:56:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1D621F8589 for ; Mon, 26 Mar 2012 02:56:11 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77D9C20C64; Mon, 26 Mar 2012 11:56:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2bbxtEnG9Sj4; Mon, 26 Mar 2012 11:56:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11D7620C5F; Mon, 26 Mar 2012 11:56:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 477C11E1D68C; Mon, 26 Mar 2012 11:56:08 +0200 (CEST) Date: Mon, 26 Mar 2012 11:56:08 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120326095608.GA33571@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] [dthaler@microsoft.com: RE: ip interface configuration data model review] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:56:12 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am forwarding a review by Dave Thaler who is not on this list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --bg08WKrSYDhXBjb5 Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS05.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.1.355.2; Sat, 24 Mar 2012 19:46:38 +0100 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CFCD20C8E for ; Sat, 24 Mar 2012 19:46:38 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 2812F3BC for ; Sat, 24 Mar 2012 19:46:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from atlas2b.jacobs-university.de ([212.201.44.15]) by localhost (demetrius4.jacobs-university.de [212.201.44.49]) (amavisd-new, port 10030) with ESMTP id XJLYXTKoJUbN for ; Sat, 24 Mar 2012 19:46:36 +0100 (CET) X-JacobsISPWhiteListed: low frontbridge.com DNSWLId 1357 Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by atlas2b.jacobs-university.de (Postfix) with ESMTPS for ; Sat, 24 Mar 2012 19:46:36 +0100 (CET) Received: from mail119-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Sat, 24 Mar 2012 18:46:22 +0000 Received: from mail119-ch1 (localhost [127.0.0.1]) by mail119-ch1-R.bigfish.com (Postfix) with ESMTP id 827332C0470; Sat, 24 Mar 2012 18:46:22 +0000 (UTC) X-SpamScore: -43 X-BigFish: VS-43(zz9371I542M1432N98dKzz1202hzz1033IL8275bh8275dh186M5eeeKz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14MLTC103.redmond.corp.microsoft.com;RD:none;EFVD:NLI Received-SPF: pass (mail119-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ;icrosoft.com ; Received: from mail119-ch1 (localhost.localdomain [127.0.0.1]) by mail119-ch1 (MessageSwitch) id 1332614779296450_18853; Sat, 24 Mar 2012 18:46:19 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail119-ch1.bigfish.com (Postfix) with ESMTP id 3A4CBC0045; Sat, 24 Mar 2012 18:46:19 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 24 Mar 2012 18:46:19 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sat, 24 Mar 2012 18:46:27 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.57]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Sat, 24 Mar 2012 11:46:28 -0700 From: Dave Thaler To: Juergen Schoenwaelder , Margaret Wasserman CC: Brian Haberman , David Kessens , Martin Bjorklund Subject: RE: ip interface configuration data model review Thread-Topic: ip interface configuration data model review Thread-Index: AQHM5q99pt8cD7nnLUmBnipzW086R5Y04ooAgEUrwhA= Date: Sat, 24 Mar 2012 18:46:27 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4C0374@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <20120208110830.GB221@elstar.local> <4F32F481.2080107@innovationslab.net> <20120209102344.GA6682@elstar.local> In-Reply-To: <20120209102344.GA6682@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-Path: dthaler@microsoft.com X-MS-Exchange-Organization-AuthSource: SHUBCAS05.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 My comments are now in marked up PDF copies at http://research.microsoft.com/~dthaler/draft-ietf-netmod-interfaces-cfg-03.= pdf http://research.microsoft.com/~dthaler/draft-ietf-netmod-ip-cfg-02.pdf http://research.microsoft.com/~dthaler/draft-ietf-netmod-routing-cfg-01.pdf I won't have time to reformulate my feedback as text email, but the above=20 links can be posted to the netmod list. I'm not a member of the list thoug= h. Do you want to post a message to the list with the links or want me to=20 (which you'll then have to approve)? -Dave > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, February 09, 2012 11:24 AM > To: Dave Thaler; Margaret Wasserman > Cc: Brian Haberman; David Kessens; Martin Bjorklund > Subject: Re: ip interface configuration data model review >=20 > Margaret and Dave, >=20 > thanks very much for volunteering to help us with this document. The > primary I-D is http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-02. > It builds on a generic interfaces configuration model defined in > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-03. The inter= faces > document is in WG last call and should be relatively stable. Both documen= ts > are fairly short - our goal is to get the essentials right and not to inc= lude > everything that might be possible in the first version. For the IP interf= ace > configuration model in particular, we need to sort out what to include an= d > what we can leave out and perhaps you can help us with that. Note that > routing specific configuration is expected to go into a separate IP routi= ng data > model, http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-01. >=20 > I am attaching an open issues list that Martin Bjorklund (the editor of d= raft- > ietf-netmod-ip-cfg-02) maintains. I think it is best if discussions go to= the > NETMOD mailing list. >=20 > /js >=20 > On Wed, Feb 08, 2012 at 05:17:37PM -0500, Brian Haberman wrote: > > Juergen, > > Margaret Wasserman and Dave Thaler are willing to help with > > reviews. Please let them know what drafts they should be reading > > within NETMOD. > > > > Regards, > > Brian >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --bg08WKrSYDhXBjb5-- From lhotka@cesnet.cz Mon Mar 26 05:35:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760C721E8094 for ; Mon, 26 Mar 2012 05:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsUM3rtWt7wI for ; Mon, 26 Mar 2012 05:35:14 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5941921E8089 for ; Mon, 26 Mar 2012 05:35:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6AFD4540A1E; Mon, 26 Mar 2012 14:35:12 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3tA9lqF6qo4; Mon, 26 Mar 2012 14:35:00 +0200 (CEST) Received: from localhost (dhcp-1072.meeting.ietf.org [130.129.16.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 031D15401AF; Mon, 26 Mar 2012 14:34:59 +0200 (CEST) From: Ladislav Lhotka To: Yi Yang In-Reply-To: <887F7D48-5183-43EA-9BF6-1D2B6405131E@cisco.com> References: <20120314235231.GG10239@nsn.com> <4F674955.2010901@cisco.com> <887F7D48-5183-43EA-9BF6-1D2B6405131E@cisco.com> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Yi Yang , netmod@ietf.org Date: Mon, 26 Mar 2012 14:34:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:35:52 -0000 Hi Yi, thank you very much for the review and helpful comments, please see my repl= ies below. Best regards, Lada * Section 4. The Design of the Core Routing Data Model +--rw routing +--rw router [name] YY> Unlike the interface name or routing-protocol name, the router YY> name is not just a local significant variable. How to guarantee YY> the router name is unique within a domain? LL> If you mean a router ID, I expect it will be defined elsewhere. LL> Some implementations define a global router ID but mostly it is LL> done per protocol. One option would be to define it here and allow LL> routing protocols to override it. +--rw name +--rw description? +--rw enabled? +--rw interfaces | +--rw interface [name] | +--rw name YY> Interface names are only configurable for virtual interfaces such YY> as tunnel interface, loopback interfaces and etc., but not YY> configurable for physical interfaces. So it would be a mix of rw YY> and ro? LL> The "name" leaf serves two purposes: (i)=C2=A0it is a list key, which LL> is required by YANG and (ii)=C2=A0reference to a logical interface LL> defined in the "/if:interfaces" subtree. There, the name may or LL> may not be configurable. | +--rw v6ur:ipv6-router-advertisements | +--rw v6ur:send-advertisements? | +--rw v6ur:max-rtr-adv-interval? | +--rw v6ur:min-rtr-adv-interval? | +--rw v6ur:managed-flag? | +--rw v6ur:other-config-flag? | +--rw v6ur:link-mtu? | +--rw v6ur:reachable-time? | +--rw v6ur:retrans-timer? | +--rw v6ur:cur-hop-limit? | +--rw v6ur:default-lifetime? | +--rw v6ur:prefix-list | +--rw v6ur:prefix [seqno] | +--rw v6ur:seqno | +--rw v6ur:prefix-spec? YY> This should be mandatory =E2=80=94 If a prefix is not specified, it will YY> not be advertised. LL> OK, I will change it to "mandatory". | +--rw v6ur:valid-lifetime? | +--rw v6ur:on-link-flag? | +--rw v6ur:preferred-lifetime? | +--rw v6ur:autonomous-flag? +--rw routing-protocols | +--rw routing-protocol [name] | +--rw name | +--rw description? | +--rw type | +--rw connected-routing-tables | | +--rw routing-table [name] | | +--rw name YY> The routing-table name of the main table and FIB should not be YY> configurable. LL> Yes, I expect every implementation will have the names of these LL> two routing tables predefined and fixed. This is explained in sec. LL> 4.3, last-but-one paragraph. Each vendor seems to have a favorite LL> naming scheme, so I didn't want to fix the names in the data LL> model. It's pretty much the same as with interface names. | | +--rw import-filter? | | +--rw export-filter? | +--rw static-routes | +--rw v4ur:ipv4 | | +--rw v4ur:route [seqno] | | +--rw v4ur:seqno | | +--rw v4ur:description? | | +--rw v4ur:outgoing-interface? | | +--rw v4ur:dest-prefix? YY> This should be mandatory for route. LL> This leaf appears here via augmentation from the LL> "ietf-ipv4-unicast-routing" module, and it is a YANG rule that LL> such a data node must not be mandatory. The same holds for LL> "v6ur:dest-prefix" below. | | +--rw v4ur:next-hop? | +--rw v6ur:ipv6 | +--rw v6ur:route [seqno] | +--rw v6ur:seqno | +--rw v6ur:description? | +--rw v6ur:outgoing-interface? | +--rw v6ur:dest-prefix? | +--rw v6ur:next-hop? +--rw route-filters | +--rw route-filter [name] | +--rw name | +--rw description? | +--rw type? +--rw routing-tables +--rw routing-table [name] +--rw name +--rw address-family? +--rw safi? +--rw description? +--ro routes YY> When new afi-safi are supported, do we expect this list to be YY> extended as well? How about to define base types for YY> outgoing-interfaces, dest-prefix and next-hop and use them here YY> instead? LL> Yes, this list would be augmented with stuff specific to the new LL> AFN/SAFI. I am not sure what you exactly mean by "base type" but LL> YANG is not object-oriented. | +--ro route | +--ro source-protocol? | +--ro last-modified? | +--ro v4ur:outgoing-interface? | +--ro v4ur:dest-prefix? | +--ro v4ur:next-hop? | +--ro v6ur:outgoing-interface? | +--ro v6ur:dest-prefix? | +--ro v6ur:next-hop? +--rw recipient-routing-tables [recipient-name] +--rw recipient-name +--rw filter? +--------+ +------------+ | direct | +---+ | | | routes |--->| F |--->| FIB | +--------+ +---+ | | +------------+ YY> Why the =E2=80=9Cdirect routes=E2=80=9D are not connected with main RT?= If direct YY> routes are connected with FIB, we should not expect to see these YY> routes in the main table, which contradicts the current practice. LL> It was so in the previous revision of the draft. I changed it to LL> allow for direct routes *not* appearing in the main routing table. LL> If necessary, "main" can be configured as a recipient of direct LL> routes from FIB. Or do you see a strong reason to change it back? ** Section 4.3. Routing Tables This also includes manipulations via the "static" pseudo-protocol. YY> This also includes manipulations via the "static" and/or "direct" YY> pseudo-protocols. LL> OK. ** Section 4.4. Routing Protocols Each routing protocol instance is connected to exactly one routing table. YY> Each routing protocol instance is connected to exactly one routing YY> table for each AFN/SAFI. LL> OK. Routes learned from the network by a routing protocol are passed to the connected routing table and vice versa - routes appearing in a routing table are passed to all routing protocols connected to the table (except "direct" and "static" pseudo-protocols) and advertised by that protocol to the network. YY> This is not true. For example, routes learned from BGP will not be YY> passed to OSPF. They can but are not by default. LL> As the next paragraph states, this exchange may be subject to a LL> route filter. It is up to the data models for routing protocols to LL> define such "business rules" and implementations will have to LL> follow them. The core routing data model only provides a LL> framework, there are (almost) no policies. Every router instance MUST contain exactly one instance of the "direct" pseudo-protocol. YY> It=E2=80=99s possible to run one =E2=80=9Cdirect=E2=80=9D protocol inst= ance per AFI/SAFI YY> instead. LL> I assume that the single "direct" instance generates the routes LL> for all address families, analogically to "static". *** Section 4.4.1. Defining New Routing Protocols o Other configuration parameters can be defined by augmenting the "routing-protocol" data node. By using the "when" statement, this augment SHOULD be made conditional and valid only if the value of the "rt:type" child leaf equals to the new protocol's identity. YY> Other operational state data can be defined by augmenting the YY> "routing-protocol" data node. By using the "when" statement, this YY> augment SHOULD be made conditional and valid only if the value of YY> the "rt:type" child leaf equals to the new protocol's identity. YY> (Examples of such operational state data are ospf link state YY> database, bgp database=E2=80=A6.) LL> OK, I will change it to "Other configuration parameters and/or LL> operational state data can be defined ...". * Section 5. IANA AFN and SAFI YANG Module enum afi { value "25"; description "AFI for L2VPN"; } YY> enum l2vpn { ... } LL> I used the "enum" labels from IANA-ADDRESS-FAMILY-NUMBERS-MIB. Of LL> course, this one seems really weird but I am not sure whether it LL> is a good idea to change it. YY> Add the following entry to "typedef subsequent-address-family": YY> YY> enum encapsulation { YY> value "7"; YY> description YY> "Encapsulation SAFI"; YY> reference YY> "RFC5512"; YY> } LL> OK, I have to update the typedef to reflect the most recent IANA LL> data. * Section 6. Routing YANG Module YY> Add the following identity to the "ietf-routing" module: YY> YY> identity allow-all-route-filter { YY> base route-filter; YY> description YY> "Route filter that allows all routes."; YY> } YY> YY> Based on section 4.5, this filter should be provided in the doc as YY> well. LL> This "allow-all" filter is equivalent to no filter at all. But LL> maybe, for the sake of symmetricity, it should be available as an LL> explicit filter. * Section 7. IPv4 Unicast Routing Module augment "/rt:routing/rt:router/rt:routing-protocols/" + "rt:routing-protocol/rt:static-routes" { description "This augment defines the configuration of the 'static' pseudo-protocol with data specific for IPv4 unicast."; container ipv4 { description "Configuration of a 'static' pseudo-protocol instance consists of a list of routes."; list route { key "seqno"; ordered-by "user"; description "A user-ordered list of static routes."; leaf seqno { type uint16; description "Sequential number of the route."; } YY> big enough? LL> Hmm, I thought it was enough, unless someone wants to copy the LL> full BGP table and paste it as static routes. But I can change it LL> to uint32, in order to allow for such pathological (but possible) LL> cases. On Thu, 22 Mar 2012 14:59:35 -0400, Yi Yang wrote: > Hi Folks, >=20 > Please see the attached for my comments. -- I put it into MS word to trac= k the changes/comments. >=20 > Regards, >=20 > Yi >=20 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Mar 26 08:04:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2F521E80CD for ; Mon, 26 Mar 2012 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qd45kDuODUz for ; Mon, 26 Mar 2012 08:04:10 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD7121E80BD for ; Mon, 26 Mar 2012 08:04:10 -0700 (PDT) Received: from localhost (dhcp-12de.meeting.ietf.org [130.129.18.222]) by mail.tail-f.com (Postfix) with ESMTPSA id 7031C1200AE5; Mon, 26 Mar 2012 17:04:07 +0200 (CEST) Date: Mon, 26 Mar 2012 17:04:04 +0200 (CEST) Message-Id: <20120326.170404.306654183.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <4F674955.2010901@cisco.com> <887F7D48-5183-43EA-9BF6-1D2B6405131E@cisco.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 15:04:10 -0000 Ladislav Lhotka wrote: > | | +--rw import-filter? > | | +--rw export-filter? > | +--rw static-routes > | +--rw v4ur:ipv4 > | | +--rw v4ur:route [seqno] > | | +--rw v4ur:seqno > | | +--rw v4ur:description? > | | +--rw v4ur:outgoing-interface? > | | +--rw v4ur:dest-prefix? > > YY> This should be mandatory for route. > > LL> This leaf appears here via augmentation from the What does "This leaf" refer to? > LL> "ietf-ipv4-unicast-routing" module, and it is a YANG rule that > LL> such a data node must not be mandatory. The same holds for > LL> "v6ur:dest-prefix" below. v6ur:dest-prefix can be mandatory since it is within a list. The node added by the augement is "v6ur:ipv6", which is not mandatory (per 3.1 of 6020). > > | | +--rw v4ur:next-hop? > | +--rw v6ur:ipv6 > | +--rw v6ur:route [seqno] > | +--rw v6ur:seqno > | +--rw v6ur:description? > | +--rw v6ur:outgoing-interface? > | +--rw v6ur:dest-prefix? > | +--rw v6ur:next-hop? /martin From lhotka@nic.cz Mon Mar 26 08:17:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504C121F8525 for ; Mon, 26 Mar 2012 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAruzcITljMX for ; Mon, 26 Mar 2012 08:17:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62321F84D4 for ; Mon, 26 Mar 2012 08:17:15 -0700 (PDT) Received: from dhcp-1072.meeting.ietf.org (dhcp-1072.meeting.ietf.org [130.129.16.114]) by mail.nic.cz (Postfix) with ESMTPSA id C41562A0100; Mon, 26 Mar 2012 17:17:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1332775033; bh=eXnJ/ubDOwoRGEtEIGtEIFcDyZ0B1ZKElLZ+nvGoc4k=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DR8UOtvoQmCGXRMNE6dI0SPKVOLmapeOV0ex35dWWXanXJwO9VOSm6G/aIPeCrGlA viRSHOYUI/TQHi2M8mtrtQixI92qvN4tDF5Z1XV+hxb3b5kcKWTDfCWmnYEMVoHFhJ hLTxJc5QCUJYUzf4IINmlPuaVRlL5mQkiusvNUzU= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120326.170404.306654183.mbj@tail-f.com> Date: Mon, 26 Mar 2012 17:17:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48AD91E2-0421-4EAA-8897-AFA6CB844D8B@nic.cz> References: <4F674955.2010901@cisco.com> <887F7D48-5183-43EA-9BF6-1D2B6405131E@cisco.com> <20120326.170404.306654183.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 15:17:17 -0000 On Mar 26, 2012, at 5:04 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> | | +--rw import-filter? >> | | +--rw export-filter? >> | +--rw static-routes >> | +--rw v4ur:ipv4 >> | | +--rw v4ur:route [seqno] >> | | +--rw v4ur:seqno >> | | +--rw v4ur:description? >> | | +--rw v4ur:outgoing-interface? >> | | +--rw v4ur:dest-prefix? >>=20 >> YY> This should be mandatory for route. >>=20 >> LL> This leaf appears here via augmentation from the >=20 > What does "This leaf" refer to? v4ur:dest-prefix >=20 >> LL> "ietf-ipv4-unicast-routing" module, and it is a YANG rule that >> LL> such a data node must not be mandatory. The same holds for >> LL> "v6ur:dest-prefix" below. >=20 > v6ur:dest-prefix can be mandatory since it is within a list. The node > added by the augement is "v6ur:ipv6", which is not mandatory (per 3.1 > of 6020). You are right, I'll make both v4ur:dest-prefix and v6ur:dest-prefix = mandatory. Lada >=20 >>=20 >> | | +--rw v4ur:next-hop? >> | +--rw v6ur:ipv6 >> | +--rw v6ur:route [seqno] >> | +--rw v6ur:seqno >> | +--rw v6ur:description? >> | +--rw v6ur:outgoing-interface? >> | +--rw v6ur:dest-prefix? >> | +--rw v6ur:next-hop? >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Mon Mar 26 13:21:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959B521E809C; Mon, 26 Mar 2012 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M02XxhttbUNm; Mon, 26 Mar 2012 13:21:07 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31621E8013; Mon, 26 Mar 2012 13:21:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT3DPr+kCjpUlFPw6OsZiHgRnx5r/wNrV@postini.com; Mon, 26 Mar 2012 13:21:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 26 Mar 2012 13:18:56 -0700 From: Kent Watsen To: "Alexander Clemm (alex)" , Juergen Schoenwaelder , "netconf@ietf.org" , "netmod@ietf.org" Date: Mon, 26 Mar 2012 13:18:37 -0700 Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0IUqpTYzkF2SPZTe2VrenNjtbAWgDLv0jgAAKH7ZA= Message-ID: <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 20:21:08 -0000 Having defined the standards and conventions for REST APIs at my company, I= have a working understanding. The fundamental question will be if the dat= astores are the "resources" on which PATCH is used or if the config hierarc= hy is mapped onto URL space. The other key decisions will be how far we ta= ke HATEOAS and custom media-types... Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Alexander Clemm (alex) Sent: Monday, March 26, 2012 2:57 PM To: Juergen Schoenwaelder; netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning A significant topic from my perspective concerns the topic of REST. Unfortunately I cannot be at IETF, but I just wanted to underscore / express my support for this topic from remote. This is also something I would be willing to spend time and engage on. =20 Kind regards --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, March 22, 2012 10:39 AM To: netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, >=20 > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: >=20 > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model >=20 > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. >=20 > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). >=20 > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. The room has been found: Room 237M is available on Monday, 26th (0900-1130). Thanks to Dan for organizing the room. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Mon Mar 26 16:00:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A228221F8573; Mon, 26 Mar 2012 16:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pLymrqZRHW9; Mon, 26 Mar 2012 16:00:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EB21F856D; Mon, 26 Mar 2012 16:00:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC16220C59; Tue, 27 Mar 2012 01:00:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t5Ax6gLmA7W8; Tue, 27 Mar 2012 01:00:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4515E209D7; Tue, 27 Mar 2012 01:00:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D60F71E1E41F; Tue, 27 Mar 2012 01:00:04 +0200 (CEST) Date: Tue, 27 Mar 2012 01:00:04 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120326230004.GA34802@elstar.local> Mail-Followup-To: Kent Watsen , "Alexander Clemm (alex)" , "netconf@ietf.org" , "netmod@ietf.org" References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 23:00:07 -0000 On Mon, Mar 26, 2012 at 01:18:37PM -0700, Kent Watsen wrote: > > Having defined the standards and conventions for REST APIs at my company, I have a working understanding. The fundamental question will be if the datastores are the "resources" on which PATCH is used or if the config hierarchy is mapped onto URL space. The other key decisions will be how far we take HATEOAS and custom media-types... > And your preferred answer to these questions is? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Mar 26 16:04:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983CC21E800F; Mon, 26 Mar 2012 16:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HThK0xo-0BED; Mon, 26 Mar 2012 16:04:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8855C21E800C; Mon, 26 Mar 2012 16:04:16 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC55E20C59; Tue, 27 Mar 2012 01:04:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Aw-9Gurmv44s; Tue, 27 Mar 2012 01:04:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67468209D7; Tue, 27 Mar 2012 01:04:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 78BFD1E1E49F; Tue, 27 Mar 2012 01:04:13 +0200 (CEST) Date: Tue, 27 Mar 2012 01:04:12 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org, netmod@ietf.org Message-ID: <20120326230411.GB34802@elstar.local> Mail-Followup-To: netconf@ietf.org, netmod@ietf.org References: <20120319101505.GA85201@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20120319101505.GA85201@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 23:04:17 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, > > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: > > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model > > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. > > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). Hi, the meeting took place but we did not manage to cover all the topics nor did we manage to explore all the details in the time we had available. Anyway, I think it is good to have such discussions in order to reflect where we are with NETCONF and where we might want to go or where we might not want to go. Attached are my meeting notes. They might be incomplete or even wrong. Participants, feel free to send me updates and corrections. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netconf-side-meeting-notes.txt" NETCONF Side Meeting, Monday 26th, 09:00-11:30, Paris IETF Meeting * Attendees Andy Bierman (AB), Martin Bjorklund (MB), Benoit Claise (BC), Bert Wijnen (BW), Mehmet Ersue (ME), Juergen Schoenwaelder (JS), Ladislav Lhotka (LL), Carl Moberg (CM), Nikolay Melnikov (NM), Vladislav Perelman (VP), David Harrington (DH) * REST API for NETCONF ** Why are REST APIs so interesting for many people? Availability of tools and APIs, (perceived) simplicity, no complexity like candidate data stores etc. REST assumes the server does not keep client state (but the client can of course keep server state). AB expresses concerns that breaking a complex configuration into a large collection of resources causes resource interaction problems, e.g. we are moving back to SNMP's peek and poke operations with complex side effects. ** How are today's NETCONF editing features used? CM says that their NETCONF management application uses candidate if it is available and usually the manager sends a single edit-config. MB says that the code to adapt to the capabilities of a server in a generic way is really small. ** Where does REST stand in the IETF? DBH says that there is a strong push towards REST APIs in the IETF. If you are living in a REST world, then learning a new tool for configuring network devices is difficult to sell. ** What does the customer want? AB says NETCONF/YANG stability is important. CM says that people want simplifying abstractions, NETCONF exposes lots of server details. MB asks since devices are complex and users want simple abstractions, where do we provide these abstractions? MB asks whether it would be valuable to provide a REST interface to high-level (network wide) management operations? AB argues for consistency of the implementations. NETCONF does not really deliver this in reality. Probably we need some more interoperability test? Do we need to explain the limits of REST when it comes to complex configuration transactions? ** Can open source help? CM likes to see a decent API for Ruby or even better a suitable C library can be used for providing various language bindings. ** Complexity questions? - Persistence? - Concurrent and conflicting changes? - Confirmed commits - configuration transactions across devices? - Preconfiguration? ** YANG mapping rules to JSON LL suggests to write a mapping of YANG to JSON. JS is concerned if YANG -> JSON and YANG -> XML -> JSON would lead to different results. The seem to be many XML -> JSON translations out there, it is not clear whether there is a standard or at least a common proposal. ** Action items? The following next steps were suggested: - Create a one slide summary explaining what NETCONF does right and that designers of other configuration protocols should consider. - Write an IPJ article that explains the important things NETCONF is doing right and which designers of other configuration protocols should consider. - Consult with APP area people to learn whether XML to JSON is somewhere on the radar. * Modeling Operational State There are interfaces that are not configured. There are addresses on interfaces that are not configured but dynamically learned. The architecture document discusses this without arriving at a conclusion. MB asks whether a operation could be a solution? MB likes to avoid large duplication of trees. JS seconds this. Some examples discussed: DHCP on an IP interface. The config of the interface just says dhcp enabled. The operational state is the IP address assigned by DHCP. As a consequence, operational state for this interface is different from its configuration state. (If config true objects are used to represent operational state. designers have to be careful to not over-constraint the data models.) * Meeting End --/04w6evG8XlLl3ft-- From andy@netconfcentral.org Mon Mar 26 20:56:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27E21E8055 for ; Mon, 26 Mar 2012 20:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmkmizwqoxoP for ; Mon, 26 Mar 2012 20:56:01 -0700 (PDT) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by ietfa.amsl.com (Postfix) with SMTP id 0AD5E21E8045 for ; Mon, 26 Mar 2012 20:56:00 -0700 (PDT) Received: (qmail 26373 invoked from network); 27 Mar 2012 03:56:00 -0000 Received: from unknown (213.41.80.49) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 27 Mar 2012 03:55:59 -0000 Message-ID: <4F713A4C.4040801@netconfcentral.org> Date: Mon, 26 Mar 2012 20:55:56 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Kent Watsen References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 03:56:01 -0000 On 03/26/2012 01:18 PM, Kent Watsen wrote: > > Having defined the standards and conventions for REST APIs at my company, I have a working understanding. The fundamental question will be if the datastores are the "resources" on which PATCH is used or if the config hierarchy is mapped onto URL space. The other key decisions will be how far we take HATEOAS and custom media-types... > The top-level issue is "what problem are we trying to solve"? IMO, NETCONF is so server-centric that application developers have too much complexity punted their way. Are we trying to pass all that complexity to a WEB app? Are we running NETCONF over HTTP or are we providing consistent CRUD operations on a YANG-specified resource model? The REST resource model has no concept of 'candidate config' or 'copy-config from running to startup'. Creation of a resource is activated right away and no extra steps for persistence are expected. There are many more issues than the mechanics of mapping CRUD operations on a subset of the datastore. IMO, fitting into the REST application toolsets and 'world view' are just as important as the mechanics. HTTP/REST is much better than NETCONF at separating meta-data and real data (HEAD operation). High level iterators (startPage=i, pageCount=N) could be much more efficient than subtree or XPath filtering. NETCONF has much more info than HTTP error codes, which is a problem that needs to be solved. REST resource discovery is also interesting. How does this interact with NETCONF capability URIs? Do we expect the WEB app to use :with-defaults, or :partial-lock? (IMO, just the YANG module capability URIs are mandatory.) > Thanks, > Kent Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) > Sent: Monday, March 26, 2012 2:57 PM > To: Juergen Schoenwaelder; netconf@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning > > A significant topic from my perspective concerns the topic of REST. > Unfortunately I cannot be at IETF, but I just wanted to underscore / > express my support for this topic from remote. This is also something I > would be willing to spend time and engage on. > > Kind regards > --- Alex > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, March 22, 2012 10:39 AM > To: netconf@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] netconf/yang side meeting in paris on monday > morning > > On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: >> Hi, >> >> a number of NETCONF / YANG contributors plan to meet on Monday morning >> 09:00-11:30 in order to informally discuss where we are with NETCONF >> and YANG adoption and if there is any useful work that people find >> valuable to spent their time on and which might be relevant from an >> IETF perspective. Some topics that have popped up several times >> include: >> >> - REST interface to NETCONF/YANG >> - Modeling operational state >> - XPATH function library for YANG >> - Issues with the candidate editing model >> >> The goal of the meeting is to dive into a certain level of technical >> depth to better understand the feasibility / complexity of potential >> solutions. People who like to attend should thus be warned that this >> meeting is not about high-level lets dream up something in the blue >> sky discussions. >> >> Note that this is an informal meeting. We plan to report in the AOB >> part of the NETMOD or NETCONF meetings (likely the NETMOD meeting >> since the NETCONF meeting is rather short). >> >> We are trying to find a suitable room. I will post a pointer once we >> have one. The fallback is to simply meet at the registration area. > > The room has been found: Room 237M is available on Monday, 26th > (0900-1130). Thanks to Dan for organizing the room. > > /js > From lhotka@nic.cz Tue Mar 27 01:59:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1A121F892D; Tue, 27 Mar 2012 01:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnQffito8kLD; Tue, 27 Mar 2012 01:59:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 99D2221F88FC; Tue, 27 Mar 2012 01:59:30 -0700 (PDT) Received: from [IPv6:2001:df8::16:38dc:f1da:a79e:a6c0] (unknown [IPv6:2001:df8:0:16:38dc:f1da:a79e:a6c0]) by mail.nic.cz (Postfix) with ESMTPSA id 8675F14045A; Tue, 27 Mar 2012 10:59:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1332838769; bh=s5sIFml1WCbiQ1WgLLAVEomijb7HVQoEfMxcSWkXMi8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UJHVlJYXkWROxNmIWjpi1qMtE1xr/xiUof5R4jmRH6O4tnOJzweR/K9Hc+guEhQsG x6eBixfsYac64/NBdfuqJj/ra5P+kdgaauYv60m1t7DOImXoT+YtTkNsKrFx7rS3fx YJzBdBIH+uH/SF1fUQsjUrr11qBLaW3ILE99UFHE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F713A4C.4040801@netconfcentral.org> Date: Tue, 27 Mar 2012 10:59:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09F23D7C-E770-4B8D-B97D-64047F7A5C2E@nic.cz> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <4F713A4C.4040801@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:59:32 -0000 On Mar 27, 2012, at 5:55 AM, Andy Bierman wrote: > On 03/26/2012 01:18 PM, Kent Watsen wrote: >>=20 >> Having defined the standards and conventions for REST APIs at my = company, I have a working understanding. The fundamental question will = be if the datastores are the "resources" on which PATCH is used or if = the config hierarchy is mapped onto URL space. The other key decisions = will be how far we take HATEOAS and custom media-types... >>=20 >=20 > The top-level issue is "what problem are we trying to solve"? >=20 > IMO, NETCONF is so server-centric that application developers have too = much > complexity punted their way. Are we trying to pass all that = complexity > to a WEB app? Are we running NETCONF over HTTP or are we providing > consistent CRUD operations on a YANG-specified resource model? I think a RESTful approach requires a different perspective, namely = "model-view-controller". This could by the way also help resolve the = issue of operational state versus configuration. Specifically: - Model is a complete set of state parameters that determines the device = behaviour, configured manually or=20 otherwise. This is the representational state in REST terms. - View can be the contents of a get (or get-operational) reply, or an = HTML rendering of the Model. - The Controller part represents the procedures for changing the Model. = For simple changes the HTTP methods=20 (PUT, POST, DELETE) can be used while complicated changes (e.g. adding = a new OSPF adjacency) might require an=20 edit-config.=20 >=20 > The REST resource model has no concept of 'candidate config' > or 'copy-config from running to startup'. Creation of a resource > is activated right away and no extra steps for persistence are = expected. A (user-specific) candidate may be treated as a special View in which a = sequence of edits performed by the user have been made. A commit then = boils down to applying the same sequence of edits to the Model = (atomically). With this approach, many of the issues concerning access = control wouldn't exist - it would only be necessary to check whether the = user has the permissions to perform all the edits. >=20 > There are many more issues than the mechanics of mapping CRUD = operations > on a subset of the datastore. IMO, fitting into the REST application > toolsets and 'world view' are just as important as the mechanics. >=20 > HTTP/REST is much better than NETCONF at separating meta-data and real = data > (HEAD operation). High level iterators (startPage=3Di, pageCount=3DN) > could be much more efficient than subtree or XPath filtering. >=20 > NETCONF has much more info than HTTP error codes, which is = a problem > that needs to be solved. IMO HTTP and NETCONF approaches are not mutually exclusive. Lada >=20 > REST resource discovery is also interesting. How does this interact > with NETCONF capability URIs? Do we expect the WEB app to use = :with-defaults, > or :partial-lock? (IMO, just the YANG module capability URIs are = mandatory.) >=20 >=20 >> Thanks, >> Kent >=20 > Andy >=20 >>=20 >>=20 >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of Alexander Clemm (alex) >> Sent: Monday, March 26, 2012 2:57 PM >> To: Juergen Schoenwaelder; netconf@ietf.org; netmod@ietf.org >> Subject: Re: [Netconf] netconf/yang side meeting in paris on monday = morning >>=20 >> A significant topic from my perspective concerns the topic of REST. >> Unfortunately I cannot be at IETF, but I just wanted to underscore / >> express my support for this topic from remote. This is also = something I >> would be willing to spend time and engage on. >>=20 >> Kind regards >> --- Alex >>=20 >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Juergen Schoenwaelder >> Sent: Thursday, March 22, 2012 10:39 AM >> To: netconf@ietf.org; netmod@ietf.org >> Subject: Re: [Netconf] netconf/yang side meeting in paris on monday >> morning >>=20 >> On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder = wrote: >>> Hi, >>>=20 >>> a number of NETCONF / YANG contributors plan to meet on Monday = morning >>> 09:00-11:30 in order to informally discuss where we are with NETCONF >>> and YANG adoption and if there is any useful work that people find >>> valuable to spent their time on and which might be relevant from an >>> IETF perspective. Some topics that have popped up several times >>> include: >>>=20 >>> - REST interface to NETCONF/YANG >>> - Modeling operational state >>> - XPATH function library for YANG >>> - Issues with the candidate editing model >>>=20 >>> The goal of the meeting is to dive into a certain level of technical >>> depth to better understand the feasibility / complexity of potential >>> solutions. People who like to attend should thus be warned that this >>> meeting is not about high-level lets dream up something in the blue >>> sky discussions. >>>=20 >>> Note that this is an informal meeting. We plan to report in the AOB >>> part of the NETMOD or NETCONF meetings (likely the NETMOD meeting >>> since the NETCONF meeting is rather short). >>>=20 >>> We are trying to find a suitable room. I will post a pointer once we >>> have one. The fallback is to simply meet at the registration area. >>=20 >> The room has been found: Room 237M is available on Monday, 26th >> (0900-1130). Thanks to Dan for organizing the room. >>=20 >> /js >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andrewmcgr@gmail.com Tue Mar 27 05:23:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46B21E809D for ; Tue, 27 Mar 2012 05:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qzRu7TI1Q90 for ; Tue, 27 Mar 2012 05:23:26 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC35321E8048 for ; Tue, 27 Mar 2012 05:23:25 -0700 (PDT) Received: by eeke51 with SMTP id e51so1840148eek.31 for ; Tue, 27 Mar 2012 05:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=FQSEM8Sd1007qojv7TtIOgKqyrf/S9Ayw54TrEJZ4jc=; b=OagBf56Oz3iZDIyKmP2tcHRRK9BY0CRFBpJmbidYxVVlVw9RW/zX/ditfHwZiYYuaf nje6WMGgv2WDkumbqHHRjoQ/Ps1035VvMFg8IdtUOtyx83T/uEuLVRg/yF53L9PnA5LK 5HLmnxzqEEhu1b4S71EmhWfSZh2j7HYSfrAigjXz3CLrbjdV+/VSsN2725IhzckaYjdA p7xOAFr0gozLDYnfmWDLg9hyjtl+ZGAqGxng96IHXSXGXJWD2MUWFnyz32A4m+J3CI// Ndesp3Fi73jIA4PzIHLDJAJiDDr9lNcG8K3xVWaXRWVHG3JJiDzI7LM4m6hUcHj4badH l9/Q== Received: by 10.14.149.129 with SMTP id x1mr3277547eej.108.1332851004878; Tue, 27 Mar 2012 05:23:24 -0700 (PDT) Received: from ?IPv6:2001:df8::96:dc7c:4a1e:b096:c897? ([2001:df8:0:96:dc7c:4a1e:b096:c897]) by mx.google.com with ESMTPS id p57sm68986173eei.8.2012.03.27.05.23.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 05:23:20 -0700 (PDT) From: Andrew McGregor Content-Type: multipart/signed; boundary="Apple-Mail=_673BCFC0-AC77-43DA-9F25-23ACB004CC86"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 27 Mar 2012 14:23:19 +0200 Message-Id: <6DD5C845-4B7E-4C12-8587-79A27DF9212E@gmail.com> To: netmod@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [netmod] draft-ietf-netmod-system-mgmt NTP server issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:23:28 -0000 --Apple-Mail=_673BCFC0-AC77-43DA-9F25-23ACB004CC86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The present NTP configuration tree in the draft looks like this: +--rw system ... +--rw ntp +--rw use-ntp? boolean +--rw ntp-server [address] +--rw address inet:host +--rw enabled boolean This does not quite line up with the way the protocol actually works. = The NTP protocol determines the server priority itself, it does not = support a priority list per se, although it has several per-server = options that bias the selection process. There are also several kinds = of association. Thus the tree should be something more like: +--rw system ... +--rw ntp +--rw use-ntp? boolean +--rw ntp-server [address] +--rw type ntp-association-type +--rw address inet:host +--rw enabled boolean +--rw iburst boolean +--rw prefer boolean +--rw true boolean where ntp-association-type is an enum with values 'server' 'peer' or = 'pool' and the booleans iburst, noselect, prefer and true are as defined = by the NTP reference implementation. A server is not expected to = synchronise with the device being configured, a peer may be expected to = synchronise with the device being configured, and 'pool' is synonymous = with 'server' except that the DNS lookup process is altered to operate = with NTP pool servers. iburst enables burst synchronisation when the = association becomes reachable, prefer increases the likelihood of = selecting the association if it is functional (i.e not obviously out of = sync), and true causes the association to be functional if the host is = reachable (irregardless of sync status, this is used if the association = is to a reference clock). These options should be sufficient for most routers and hosts that are = not NTP reference clocks and do not have special security requirements. = It could be extended to include the authentication and = broadcast/multicast features, however for a generic system management = draft I do not see the need. Andrew --Apple-Mail=_673BCFC0-AC77-43DA-9F25-23ACB004CC86 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMjcxMjIzMTlaMCMGCSqGSIb3DQEJBDEWBBQDIEAv eyFvDaBkJmP7JMD8gqviPTCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBAKxIJtQs09v2tzovrXBRxqhi9edKiSnFC0R/OO8LutuVHt4PBaYWyjgr uVCZJdgk4kRmg3oWuBit0jEXWp8YvYYyk+J9HGHel04cN/E0KOcztcoPHO7nAF/n6BYQEpM7yCKp aqjzqqHz13KaqwwPvAcVpeNJkq2XGzNtTYF903m9RqWVUrLFUDrQXMoK/jtgfVoVYOnlpw4g8N/h IIfqn6xAx4t3Y74anr3D4tPRGIzgVj+WtueBJpcmVLpjJkI+9N5e6vmm5CPpkvC26LJUaSlTFIbw B2ECnb2ZRirk9rulHtLMIpB7fvCcmO/S6vmZnbZtOWlJTSG788e2PJAKvzsAAAAAAAA= --Apple-Mail=_673BCFC0-AC77-43DA-9F25-23ACB004CC86-- From andy@netconfcentral.org Tue Mar 27 05:27:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4023221F892B for ; Tue, 27 Mar 2012 05:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV8tWmknJx9b for ; Tue, 27 Mar 2012 05:27:35 -0700 (PDT) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) by ietfa.amsl.com (Postfix) with ESMTP id 47D1021F86D6 for ; Tue, 27 Mar 2012 05:27:31 -0700 (PDT) Received: from [10.59.89.170] ([213.41.80.49]) by p3plsmtpa06-01.prod.phx3.secureserver.net with id qcTR1i00G13qFst01cTVb4; Tue, 27 Mar 2012 05:27:30 -0700 Message-ID: <4F71B22D.3020506@netconfcentral.org> Date: Tue, 27 Mar 2012 05:27:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Andrew McGregor References: <6DD5C845-4B7E-4C12-8587-79A27DF9212E@gmail.com> In-Reply-To: <6DD5C845-4B7E-4C12-8587-79A27DF9212E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt NTP server issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:27:36 -0000 On 03/27/2012 05:23 AM, Andrew McGregor wrote: > The present NTP configuration tree in the draft looks like this: > > +--rw system > ... > +--rw ntp > +--rw use-ntp? boolean > +--rw ntp-server [address] > +--rw address inet:host > +--rw enabled boolean > > This does not quite line up with the way the protocol actually works. The NTP protocol determines the server priority itself, it does not support a priority list per se, although it has several per-server options that bias the selection process. There are also several kinds of association. > > Thus the tree should be something more like: > > +--rw system > ... > +--rw ntp > +--rw use-ntp? boolean > +--rw ntp-server [address] > +--rw type ntp-association-type > +--rw address inet:host > +--rw enabled boolean > +--rw iburst boolean > +--rw prefer boolean > +--rw true boolean > > where ntp-association-type is an enum with values 'server' 'peer' or 'pool' and the booleans iburst, noselect, prefer and true are as defined by the NTP reference implementation. A server is not expected to synchronise with the device being configured, a peer may be expected to synchronise with the device being configured, and 'pool' is synonymous with 'server' except that the DNS lookup process is altered to operate with NTP pool servers. iburst enables burst synchronisation when the association becomes reachable, prefer increases the likelihood of selecting the association if it is functional (i.e not obviously out of sync), and true causes the association to be functional if the host is reachable (irregardless of sync status, this is used if the association is to a reference clock). > > These options should be sufficient for most routers and hosts that are not NTP reference clocks and do not have special security requirements. It could be extended to include the authentication and broadcast/multicast features, however for a generic system management draft I do not see the need. > thanks -- I will change the draft to match your data model > Andrew > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From kwatsen@juniper.net Tue Mar 27 09:36:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7621E8174; Tue, 27 Mar 2012 09:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez0UZ+hKm1C9; Tue, 27 Mar 2012 09:36:04 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4C49621E80EC; Tue, 27 Mar 2012 09:36:04 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HscNmZtqxgS1OZi/Z7W+2+XyrveCJM@postini.com; Tue, 27 Mar 2012 09:36:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 27 Mar 2012 09:34:38 -0700 From: Kent Watsen To: Andy Bierman Date: Tue, 27 Mar 2012 09:34:32 -0700 Thread-Topic: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0LzYdW1y/XcOamSe6teKsCzhHvpgAZhBuQ Message-ID: <84600D05C20FF943918238042D7670FD48C031EAE8@EMBX01-HQ.jnpr.net> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <4F713A4C.4040801@netconfcentral.org> In-Reply-To: <4F713A4C.4040801@netconfcentral.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:36:06 -0000 Andy Bierman writes: > > The top-level issue is "what problem are we trying to solve"? Yes, this is the top-level question. It seems to that there are 3 use-cases: 1. off-box scripts 2. off-box NMS apps 3. on-box web interface Did I miss any? Considering these in turn: 1. off-box scripts The API should be simple to use via a scripting language. HTTP is ubiquitous, every scripting language has built-in=20 support. NETCONF API bindings can be provided, but they'll never be built into the language nor be as popular. 2. off-box NMS apps The complexity of the API doesn't matter as much as the scalability and performance of the protocol. NETCONF may have the edge here, though HTTP caching servers may make up for much of that. 3. on-box web-interface Assuming the web-interface is AJAX/AJAJ, then a REST interface would be preferred - not only because the HTTP bindings are built into Javascript, but also because the client could use JSON and there would be no uncertainty for if the REST API is available, since it uses the same protocol as the web interface. Thoughts? Kent From kwatsen@juniper.net Tue Mar 27 10:39:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5091F0C57; Tue, 27 Mar 2012 10:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHE-TECxw+Bq; Tue, 27 Mar 2012 10:39:09 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB91F0C56; Tue, 27 Mar 2012 10:39:09 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT3H7Okm3+F2baiP+0HET0nF3tMnJBzBs@postini.com; Tue, 27 Mar 2012 10:39:09 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 27 Mar 2012 10:38:45 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Tue, 27 Mar 2012 10:38:43 -0700 Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0LpDByKe6p7cu3TKmd42ATr7o2fgAjoC0w Message-ID: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <20120326230004.GA34802@elstar.local> In-Reply-To: <20120326230004.GA34802@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:39:10 -0000 Juergen writes: > >And your preferred answer to these questions is? Just thinking out loud. We know that a YANG module can define config/state= , RPCs, and notifications. From NETCONF, we know that the device can have c= onfig datastores and capabilities. Lastly, from REST, we know that HTTP is= the protocol (not NETCONF). Given its simplicity, my preference would be to model each datastore as sin= gle resource (not a hierarchy of URLs). For granular retrievals, I would u= se XPath with GET; for granular updates, I would use PATCH (RFC 5789) - thi= s implies using ETags and If-Match. For the PATCH document format, we coul= d define one to be like the body of an operation. For RPCs, I= would define "methods" (more on this later) and for notifications, I would= define a long-poll (comet) interface. Lastly, to support capabilities exc= hange, I would define RFC 6022's "netconf-state" as a top-level resource. While I'm generally a proponent for custom media-types, I envision them as = being more useful when defined by the vendor than IETF. We might define a = few like: datastore, netconf-state, and edit-config. That said, "datastore= " might be better identified as "application/json" and/or "application/xml"= , so the document can be defined in the vendor's namespace. As for HATEOAS, I don't see the use-case for supporting clients that aren't= explicitly programmed to know that they're connecting to a device. Thus, = I think that it's OK for us to assume the client knows about the /netconf-s= tate and / resources without having to discover them via the Hos= t Metadata service (RFC 6415). If we want something more elegant than retu= rning 404 on /netconf-state, we could register a single element in t= he .well-known XDP for a "netconf" relation. What do you think? Kent From j.schoenwaelder@jacobs-university.de Tue Mar 27 11:11:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0B21E80AE; Tue, 27 Mar 2012 11:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.185 X-Spam-Level: X-Spam-Status: No, score=-102.185 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxNk58U9Lo7W; Tue, 27 Mar 2012 11:11:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6947121E808D; Tue, 27 Mar 2012 11:11:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D88320C7C; Tue, 27 Mar 2012 20:11:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aaG-H4my6fKP; Tue, 27 Mar 2012 20:11:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECC6620C75; Tue, 27 Mar 2012 20:11:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 182511E1FD0A; Tue, 27 Mar 2012 20:11:08 +0200 (CEST) Date: Tue, 27 Mar 2012 20:11:08 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120327181108.GA37080@elstar.local> Mail-Followup-To: Kent Watsen , "Alexander Clemm (alex)" , "netconf@ietf.org" , "netmod@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 18:11:11 -0000 On Tue, Mar 27, 2012 at 10:38:43AM -0700, Kent Watsen wrote: > > Juergen writes: > > > >And your preferred answer to these questions is? > > Just thinking out loud. We know that a YANG module can define config/state, RPCs, and notifications. From NETCONF, we know that the device can have config datastores and capabilities. Lastly, from REST, we know that HTTP is the protocol (not NETCONF). > > Given its simplicity, my preference would be to model each datastore as single resource (not a hierarchy of URLs). For granular retrievals, I would use XPath with GET; for granular updates, I would use PATCH (RFC 5789) - this implies using ETags and If-Match. For the PATCH document format, we could define one to be like the body of an operation. For RPCs, I would define "methods" (more on this later) and for notifications, I would define a long-poll (comet) interface. Lastly, to support capabilities exchange, I would define RFC 6022's "netconf-state" as a top-level resource. There is a JSON patch format and it would be nice to use that together with HTTP PATCH (RFC 5789) to do modifications. > While I'm generally a proponent for custom media-types, I envision them as being more useful when defined by the vendor than IETF. We might define a few like: datastore, netconf-state, and edit-config. That said, "datastore" might be better identified as "application/json" and/or "application/xml", so the document can be defined in the vendor's namespace. > > As for HATEOAS, I don't see the use-case for supporting clients that aren't explicitly programmed to know that they're connecting to a device. Thus, I think that it's OK for us to assume the client knows about the /netconf-state and / resources without having to discover them via the Host Metadata service (RFC 6415). If we want something more elegant than returning 404 on /netconf-state, we could register a single element in the .well-known XDP for a "netconf" relation. > > What do you think? I share the concern that exposing fine grained resources might be cumbersome. But we would need to support filtered retrieval in some way. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 27 11:21:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0017821E80AE; Tue, 27 Mar 2012 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd43E85Sx9M2; Tue, 27 Mar 2012 11:21:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DB70D21E808D; Tue, 27 Mar 2012 11:21:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1210920CA8; Tue, 27 Mar 2012 20:21:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4QsT3BFh6_X7; Tue, 27 Mar 2012 20:21:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8163F20C8E; Tue, 27 Mar 2012 20:21:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB0A21E1FD50; Tue, 27 Mar 2012 20:21:53 +0200 (CEST) Date: Tue, 27 Mar 2012 20:21:53 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120327182153.GB37080@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , "Alexander Clemm (alex)" , "netconf@ietf.org" , "netmod@ietf.org" References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <4F713A4C.4040801@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C031EAE8@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48C031EAE8@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 18:21:56 -0000 On Tue, Mar 27, 2012 at 09:34:32AM -0700, Kent Watsen wrote: > Considering these in turn: > > 1. off-box scripts > > The API should be simple to use via a scripting language. > HTTP is ubiquitous, every scripting language has built-in > support. NETCONF API bindings can be provided, but they'll > never be built into the language nor be as popular. > > 2. off-box NMS apps > > The complexity of the API doesn't matter as much as the > scalability and performance of the protocol. NETCONF may > have the edge here, though HTTP caching servers may make > up for much of that. > > 3. on-box web-interface > > Assuming the web-interface is AJAX/AJAJ, then a REST interface > would be preferred - not only because the HTTP bindings are > built into Javascript, but also because the client could use > JSON and there would be no uncertainty for if the REST API is > available, since it uses the same protocol as the web interface. > > Thoughts? But are all three use cases at the end not boiling down to the same argument, namely the ubiquity of HTTP and JSON support? For me, the question really is whether we are fine with NETCONF being used as a well designed and optimized configuration protocol of bigger networking gear or whether we want to reach out of that niche and seek wider application on say constrained devices or as an interface to network managers (that is software components that configure collections of boxes to provide a certain service) etc. If we want to reach out, then a REST interface is going to make a difference. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Tue Mar 27 12:50:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B8C21E80AD; Tue, 27 Mar 2012 12:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezCyothCMmfN; Tue, 27 Mar 2012 12:50:31 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 01BD321E804B; Tue, 27 Mar 2012 12:50:30 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT3IaAxnTpN0dTXg06SefWt/Swnaxv0VC@postini.com; Tue, 27 Mar 2012 12:50:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 27 Mar 2012 12:50:18 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Tue, 27 Mar 2012 12:50:14 -0700 Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0MRQCkJgxV6tpfTAyH/eCRbcL62AACllbg Message-ID: <84600D05C20FF943918238042D7670FD48C031ED4D@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> <20120327181108.GA37080@elstar.local> In-Reply-To: <20120327181108.GA37080@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Alexander Clemm \(alex\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:50:32 -0000 > There is a JSON patch format and it would be nice to use that together with HTTP PATCH= (RFC 5789) to do modifications. And the XML Patch format is defined in RFC 5261. If we do this, we'd need = to support both XML and JSON. > we would need to support filtered retrieval in some way. Following mimics the example given in RFC 6241 for the Xpath capability: ---Request--- (pretend I escaped the URL yuk) GET /running?xmlns:t=3D"http://example.com/schema/1.2/config"& select=3D"/t= :top/t:users/t:user[t:name=3D'fred']" HTTP/1.1 Host: acme.company.com Authorization: Basic xxxxxxxxxxxxxxxxxxx Accept: application/xml; application/json =20 ---Response--- HTTP/1.1 200 OK Content-Type: application/xml Content-Length: nnn fred 2 From alex@cisco.com Mon Mar 26 11:56:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032D621E80E4; Mon, 26 Mar 2012 11:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdIyKgAyUcrX; Mon, 26 Mar 2012 11:56:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 185C521E80BD; Mon, 26 Mar 2012 11:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=2317; q=dns/txt; s=iport; t=1332788207; x=1333997807; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=uEb7NO6ZadCQuo8WdnxHG+Qq5FmL24+dnrqEXyMZp1Y=; b=kSM2dwc9nla1PeEF6p/ZT/uasyBJqpV9ZPhZqdeRQRFQTD4L+jY2YR0p Ffxo704ZHlb7cl3FcphvgWEDHuh/WYJKGAnfHxWo3Z8M909muj+uGv+bs 4cHX6GCvJfUeh3/0tYtTxXk7y+lPemOgxgGwgCV1d5fapyglKc3WEASqI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGe7cE+rRDoI/2dsb2JhbABBA7g2gQeCCQEBAQQBAQEPAR0KNBcCAgIBCA4CAQQBAQEKBhcBBgEaDB8JCAEBBAESCBMHh2cBC5o8jVGRJQSNe4JGYwSIV5tOgWiDBw X-IronPort-AV: E=Sophos;i="4.73,652,1325462400"; d="scan'208";a="35151063" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 26 Mar 2012 18:56:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2QIui5m016461; Mon, 26 Mar 2012 18:56:44 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 11:56:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 11:56:42 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120322173850.GC23587@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0IUqpTYzkF2SPZTe2VrenNjtbAWgDLv0jg References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> From: "Alexander Clemm (alex)" To: "Juergen Schoenwaelder" , , X-OriginalArrivalTime: 26 Mar 2012 18:56:44.0451 (UTC) FILETIME=[301D8F30:01CD0B82] X-Mailman-Approved-At: Wed, 28 Mar 2012 09:43:00 -0700 Subject: Re: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:56:48 -0000 A significant topic from my perspective concerns the topic of REST. Unfortunately I cannot be at IETF, but I just wanted to underscore / express my support for this topic from remote. This is also something I would be willing to spend time and engage on. =20 Kind regards --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, March 22, 2012 10:39 AM To: netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, >=20 > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: >=20 > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model >=20 > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. >=20 > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). >=20 > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. The room has been found: Room 237M is available on Monday, 26th (0900-1130). Thanks to Dan for organizing the room. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Wed Mar 28 23:40:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A226E21E80E0 for ; Wed, 28 Mar 2012 23:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EloNfPaTQB3l for ; Wed, 28 Mar 2012 23:40:34 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 911E621E80D6 for ; Wed, 28 Mar 2012 23:40:34 -0700 (PDT) Received: from localhost (dhcp-43e4.meeting.ietf.org [130.129.67.228]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D65812008BF for ; Thu, 29 Mar 2012 08:40:32 +0200 (CEST) Date: Thu, 29 Mar 2012 08:40:30 +0200 (CEST) Message-Id: <20120329.084030.108113872.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:40:35 -0000 Hi, Here are my comments on draft-ietf-netmod-routing-cfg-02. o 4.1 Each router instance in the core routing data model represents a (logical) router whose configuration and operation is independent of other router instances. Why do we need this extra list (/routing/router)? Can you examplify when more than one list entry would be used? o 4.1 Logical network interfaces must be assigned to a router instance What is a "Logical network interface"? draft-ietf-netmod-interfaces-cfg does not use this term. o 4.2 s/destination-prefix/dest-prefix/ OR the other way around in the data model. o 4.3 You say that at least two routing tables MUST be present. Can we change the name of a routing table to be: type union { type enumeration { enum fib; enum main; } type string; } This makes it clear which table is the fib and which is main. Also, on my linux box, I can see the FIB, but what about main? Is it always present? o 4.4 Each routing protocol instance is connected to exactly one routing table. Where is this "exactly one" property in the data model? "connected-routing-tables" has a list, so its seems a routing protocol can be connected to 0 or more tables? o 4.4 By default, every routing protocol instance SHOULD be connected to the main routing table. I do not understand this sentence. What does it mean in terms of the configuration? o 4.4 Every router instance MUST contain exactly one instance of the "direct" pseudo-protocol. What does this mean? o 4.4.1 s/It is recommended/It is RECOMMENDED/ o leaf cur-hop-limit { type uint8; default "64"; Is this default really correct? It doesn't match the text: The default should be set to the value specified in IANA Assigned Numbers that was in effect at the time of implementation. I suggest you remove the default statement, and change the text to something like If not explicitly configured, the value to be used in the Cur Hop Limit field should be the value specified in IANA Assigned Numbers that was in effect at the time of implementation. /martin From mbj@tail-f.com Wed Mar 28 23:48:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96421F85F9 for ; Wed, 28 Mar 2012 23:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs09f7NgM3VS for ; Wed, 28 Mar 2012 23:48:23 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6486021F85F8 for ; Wed, 28 Mar 2012 23:48:23 -0700 (PDT) Received: from localhost (dhcp-43e4.meeting.ietf.org [130.129.67.228]) by mail.tail-f.com (Postfix) with ESMTPSA id 769F912008BF; Thu, 29 Mar 2012 08:48:22 +0200 (CEST) Date: Thu, 29 Mar 2012 08:48:20 +0200 (CEST) Message-Id: <20120329.084820.309134913.mbj@tail-f.com> To: dthaler@microsoft.com From: Martin Bjorklund In-Reply-To: <20120326095608.GA33571@elstar.local> References: <20120326095608.GA33571@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] [dthaler@microsoft.com: RE: ip interface configuration data model review] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:48:24 -0000 SGkgRGF2ZSwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZpZXcsIGl0IGlzIHZl cnkgaGVscGZ1bCENCg0KSSBoYXZlIG1hZGUgY2hhbmdlcyBhY2NvcmRpbmcgdG8geW91ciBjb21t ZW50cyBpbiBtb3N0IGNhc2VzLiAgQmVsb3cNCmFyZSBteSBjb21tZW50cyBvbiBzb21lIG9mIHRo ZSBpc3N1ZXM6DQoNCmRyYWZ0LWlldGYtbmV0bW9kLWludGVyZmFjZXMtY2ZnDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQpEVDU6DQoNCj4+ICBsZWFmIG5hbWUgeyAuLi4NCj4+ ICAgIFRoaXMgbGVhZiBNQVkgYmUgbWFwcGVkIHRvIGlmTmFtZSBieSBhbiBpbXBsZW1lbnRhdGlv bi4gIFN1Y2ggYW4NCj4+ICAgIGltcGxlbWVudGF0aW9uIE1BWSByZXN0cmljdCB0aGUgYWxsb3dl ZCB2YWx1ZXMgZm9yIHRoaXMgbGVhZiBzbw0KPj4gICAgdGhhdCBpdCBtYXRjaGVzIHRoZSByZXN0 cmljdGlvbnMgb2YgaWZOYW1lLg0KDQo+IFdoYXRzIHRoZSBhbHRlcm5hdGl2ZT8gVGhhdCBpcywg aWYgYW4gaW1wbGVtZW50YXRpb24gbWFwcyBpdCB0bw0KPiBpZk5hbWUsIHdoYXQgZWxzZSBjb3Vs ZCBpdCBkbyBiZXNpZGVzIHJlc3RyaWN0aW5nIHRoZSBhbGxvd2VkDQo+IHZhbHVlcz8gSWYgaXQg ZG9lc26idCByZXN0cmljdCwgSSBkb26idCBzZWUgaG93IGl0IGNvdWxkIGJlIG1hcHBlZA0KPiB0 byBpZk5hbWUuDQoNClRoZSBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB1cCB0byB0aGUgaW1wbGVtZW50 YXRpb24uICBGb3IgZXhhbXBsZSwgaXQNCmNvdWxkIGRvIHNvbWUga2luZCBvZiB0cmFuc2Zvcm0s IG9yIGl0IGNvdWxkIHNpbXBseSBwdXQgYSB6ZXJvLWxlbmd0aA0Kc3RyaW5nIGluIGlmTmFtZSBm b3IgdGhpcyBpbnRlcmZhY2UuDQoNCg0KDQoNCmRyYWZ0LWlldGYtbmV0bW9kLWlwLWNmZw0KPT09 PT09PT09PT09PT09PT09PT09PT09DQoNCkRUNDoNCg0KPiAgIFRoZXJlIGFwcGVhciB0byBiZSBz b21lIGNvbmZpZ3VyYWJsZSwgbm9uLXJvdXRpbmctIHJlbGF0ZWQsIG9iamVjdHMNCj4gICBpbiB0 aGUgSVAtTUlCIHRoYXQgYXJlIG5vdCBjb25maWd1cmFibGUgdmlhIHRoaXMgZG9jdW1lbnQuIEkg d291bGQNCj4gICBleHBlY3QgdGhlcmUgdG8gYmUgYW4gZXhwbGFuYXRpb24gb2Ygd2h5IHRoZXkg d2VyZSBvbWl0dGVkOg0KPiANCj4gICBpcEFkZHJlc3NTdGF0dXMgKHdoaWNoIGNhbiBiZSB1c2Vk IHRvIG1hcmsgYSBzdGF0aWMgYWRkcmVzcyBhcw0KPiAgICAgICBkZXByZWNhdGVkIHdpdGhvdXQg ZGVsZXRpbmcgaXQpLA0KDQpJcyB0aGlzIHJlYWxseSBhIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVy LCBpLmUuIHNhdmVkIHRvIG5vbi12b2xhdGlsZQ0Kc3RvcmFnZT8gIElmIGl0IGlzLCBJIGFzc3Vt ZSBvbmx5IGEgc3Vic2V0IG9mIHRoZSB2YWx1ZXMgY2FuIGJlDQp3cml0dGVuPyAgQWxzbywgaWYg dGhlIG5ldyB2YWx1ZSBjYW4gYmUgd3JpdHRlbiBwcm9iYWJseSBkZXBlbmRzIG9uDQp0aGUgY3Vy cmVudCB2YWx1ZSAoZS5nLiwgSSBhc3N1bWUgSSBjYW5ub3QgbWFrZSBhICdkdXBsaWNhdGUnIGFk ZHJlc3MNCidwcmVmZXJyZWQnPw0KDQo+IGlwRGVmYXVsdFRUTA0KPiBpcHY2SXBEZWZhdWx0SG9w TGltaXQNCg0KSW4gUkZDIDQ4NjIsICJDdXJIb3BMaW1pdCIgaXMgbGlzdGVkIGFzIGEgcGVyLWlu dGVyZmFjZSB2YXJpYWJsZS4NClRoZXJlIGlzIG5vIGNvbmZpZ3VyYXRpb24gdmFyaWFibGUgZGVm aW5lZCBpbiA0ODYyLg0KDQo+IGlwTmV0VG9QaHlzaWNhbEFkZHJlc3NUYWJsZQ0KDQpUaGlzIHRh YmxlIGl0IGRlZmluZWQgdG8gbm90IGJlIHN0b3JlZCBpbiBub24tdm9sYXRpbGUgbWVtb3J5LCBz byBpdA0Kd291bGRuJ3QgbWFwIHRvIGNvbmZpZyBoZXJlLg0KDQotLS0tLS0tLS0tLS0tLS0NCg0K RFQ5Og0KDQo+IGR1cC1hZGRyLWRldGVjdC10cmFuc21pdHMgaXMgTk9UIGp1c3QgZm9yICJhdXRv Y29uZmlndXJhdGlvbiIsIGl0DQo+IGNvbnRyb2xzIERBRCBmb3IgbWFudWFsbHkgY29uZmlndXJl ZCBzdGF0aWMgYWRkcmVzc2VzIHRvby4gUkZDIDQ4NjINCj4gc3RhdGVzOiAiVGhlIHRlc3Qgc2hv dWxkIGluZGl2aWR1YWxseSBiZSBwZXJmb3JtZWQgb24gYWxsIGFkZHJlc3Nlcw0KPiBvYnRhaW5l ZCBtYW51YWxseSwgdmlhIHN0YXRlbGVzcyBhZGRyZXNzIGF1dG9jb25maWd1cmF0aW9uLCBvciB2 aWENCj4gREhDUHY2LiINCg0KUmlnaHQuLi4NCg0KRFQxMToNCg0KPiBTaW5jZSB0aGUgaW50ZW50 IGlzIHRvIGNvbmZpZ3VyZSBwYXJhbWV0ZXJzIHJlbGF0ZWQgdG8gYWRkcmVzc2luZywNCj4gbm90 IGp1c3QgdGhlIGFkZHJlc3NlcyB0aGVtc2VsdmVzLCB0aGVyZSBhcHBlYXJzIHRvIGJlIGEgY291 cGxlIG1vcmUNCj4gdGhpbmdzIG1pc3Npbmc6IFNlZSBURU1QX1ZBTElEX0xJRkVUSU1FIGFuZCBU RU1QX1BSRUZFUlJFRF9MSUZFVElNRQ0KDQouLi5zbyBJIG1vdmVkIGR1cC1hZGRyLWRldGVjdC10 cmFuc21pdHMgb25lIGxldmVsIHVwLCBhbmQgYWRkZWQNCnBhcmFtZXRlcnMgZnJvbSBSRkMgNDk0 MToNCg0KICAgICAgICAgKy0tcncgaXB2Ng0KICAgICAgICAgICAgLi4uDQogICAgICAgICAgICAr LS1ydyBkdXAtYWRkci1kZXRlY3QtdHJhbnNtaXRzPyAgIHVpbnQzMg0KICAgICAgICAgICAgKy0t cncgYXV0b2NvbmYNCiAgICAgICAgICAgICAgICstLXJ3IGNyZWF0ZS1nbG9iYWwtYWRkcmVzc2Vz PyAgICAgICAgYm9vbGVhbg0KICAgICAgICAgICAgICAgKy0tcncgY3JlYXRlLXRlbXBvcmFyeS1h ZGRyZXNzZWQ/ICAgICBib29sZWFuDQogICAgICAgICAgICAgICArLS1ydyB0ZW1wb3JhcnktdmFs aWQtbGlmZXRpbWU/ICAgICAgIHVpbnQzMg0KICAgICAgICAgICAgICAgKy0tcncgdGVtcG9yYXJ5 LXByZWZlcnJlZC1saWZldGltZT8gICB1aW50MzINCg0KRG9lcyB0aGlzIHNlZW0gdG8gYmUgY29y cmVjdD8NCg0KDQoNCi9tYXJ0aW4NCg== From phil@juniper.net Thu Mar 29 04:34:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7FA21F8992 for ; Thu, 29 Mar 2012 04:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m5JR6rkojI2 for ; Thu, 29 Mar 2012 04:34:40 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id D9CC021F89A7 for ; Thu, 29 Mar 2012 04:34:37 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RIykRRhjWztg5rV3OZQ6Kf69B3xadw@postini.com; Thu, 29 Mar 2012 04:34:40 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 04:34:19 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q2TBYI123765; Thu, 29 Mar 2012 04:34:18 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q2TBYcIZ061366; Thu, 29 Mar 2012 07:34:39 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201203291134.q2TBYcIZ061366@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120329.084030.108113872.mbj@tail-f.com> Date: Thu, 29 Mar 2012 07:34:38 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:34:41 -0000 Martin Bjorklund writes: >o 4.1 > Each router instance in the core routing data model represents a > (logical) router whose configuration and operation is independent > of other router instances. > > Why do we need this extra list (/routing/router)? Can you > examplify when more than one list entry would be used? LRs are independent of each other, but must exist in the configuration of the full device. >o 4.2 > s/destination-prefix/dest-prefix/ > OR the other way around in the data model. Other way please. Full words are so much easy to standardize on. > Also, on my linux box, I can see the FIB, but what about main? Is > it always present? No. The FIB can be built from a set of routing tables that are protocol-specific (inet, inet6, etc) where no specific one can be called "main" (without upsetting the v6 folks ;^). If you keep it, "rib" might be a better name than "main". Also there is a lot of information in the other routing tables that isn't needed in the FIB. >o 4.4 > > Every router instance MUST contain exactly one instance of the > "direct" pseudo-protocol. > > What does this mean? I think this means routers without real interfaces are not interesting. And while that may be true, interfaces can appear and disappear (hot plug), so saying that I MUST have one is not good. Thanks, Phil From mbj@tail-f.com Thu Mar 29 05:12:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E8321F88F2 for ; Thu, 29 Mar 2012 05:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOls36tDmFKW for ; Thu, 29 Mar 2012 05:12:03 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E514D21F86E3 for ; Thu, 29 Mar 2012 05:12:02 -0700 (PDT) Received: from localhost (dhcp-1682.meeting.ietf.org [130.129.22.130]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E9181200D86; Thu, 29 Mar 2012 14:12:01 +0200 (CEST) Date: Thu, 29 Mar 2012 14:11:59 +0200 (CEST) Message-Id: <20120329.141159.492740978.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201203291134.q2TBYcIZ061366@idle.juniper.net> References: <20120329.084030.108113872.mbj@tail-f.com> <201203291134.q2TBYcIZ061366@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:12:03 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >o 4.1 > > Each router instance in the core routing data model represents a > > (logical) router whose configuration and operation is independent > > of other router instances. > > > > Why do we need this extra list (/routing/router)? Can you > > examplify when more than one list entry would be used? > > LRs are independent of each other, but must exist in the > configuration of the full device. I guess my concern is if this concept is similiar enough in different vendors' routers that it make sense to standardize it like this. A device that do not support multiple LRs is still required to have this extra layer. Also, if this data model has this extra list on the top, do we need to do the same in other data models? > >o 4.4 > > > > Every router instance MUST contain exactly one instance of the > > "direct" pseudo-protocol. > > > > What does this mean? > > I think this means routers without real interfaces are not > interesting. And while that may be true, interfaces can > appear and disappear (hot plug), so saying that I MUST > have one is not good. Ok. I meant what does this "MUST" mean for an implementation? /martin From phil@juniper.net Thu Mar 29 06:07:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3853021F8453 for ; Thu, 29 Mar 2012 06:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXJuJ1cvPEOb for ; Thu, 29 Mar 2012 06:07:09 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 699F821F8992 for ; Thu, 29 Mar 2012 06:07:06 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT3ReeQfxM+WBI+OrMbg/D8+7L+Vh4QYs@postini.com; Thu, 29 Mar 2012 06:07:08 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 06:06:50 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q2TD6o151712; Thu, 29 Mar 2012 06:06:50 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q2TD7Ax1061867; Thu, 29 Mar 2012 09:07:10 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201203291307.q2TD7Ax1061867@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120329.141159.492740978.mbj@tail-f.com> Date: Thu, 29 Mar 2012 09:07:10 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:07:14 -0000 Martin Bjorklund writes: >I guess my concern is if this concept is similiar enough in different >vendors' routers that it make sense to standardize it like this. A >device that do not support multiple LRs is still required to have this >extra layer. We put LRs in a distinct container, since the base device has functionality outside the LR. You should not few the base device as a "special" LR. >Also, if this data model has this extra list on the top, do we need to >do the same in other data models? > >> >o 4.4 >> > >> > Every router instance MUST contain exactly one instance of the >> > "direct" pseudo-protocol. >> > >> > What does this mean? >> >> I think this means routers without real interfaces are not >> interesting. And while that may be true, interfaces can >> appear and disappear (hot plug), so saying that I MUST >> have one is not good. > >Ok. > >I meant what does this "MUST" mean for an implementation? IMHO it should be removed. Thanks, Phil From mbj@tail-f.com Thu Mar 29 06:10:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5C221F8B29 for ; Thu, 29 Mar 2012 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiTe5CzB37cV for ; Thu, 29 Mar 2012 06:10:27 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49821F8B2B for ; Thu, 29 Mar 2012 06:10:27 -0700 (PDT) Received: from localhost (dhcp-1682.meeting.ietf.org [130.129.22.130]) by mail.tail-f.com (Postfix) with ESMTPSA id 85AA41200054; Thu, 29 Mar 2012 15:10:26 +0200 (CEST) Date: Thu, 29 Mar 2012 15:10:24 +0200 (CEST) Message-Id: <20120329.151024.231403729.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201203291307.q2TD7Ax1061867@idle.juniper.net> References: <20120329.141159.492740978.mbj@tail-f.com> <201203291307.q2TD7Ax1061867@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:10:28 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >I guess my concern is if this concept is similiar enough in different > >vendors' routers that it make sense to standardize it like this. A > >device that do not support multiple LRs is still required to have this > >extra layer. > > We put LRs in a distinct container, since the base device > has functionality outside the LR. You should not few the > base device as a "special" LR. So do you think the same should be done here? /routing/ /logical-router/ /martin From phil@juniper.net Thu Mar 29 07:21:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358AF21E8174 for ; Thu, 29 Mar 2012 07:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJtYFt3JYEQg for ; Thu, 29 Mar 2012 07:21:14 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9308121E8124 for ; Thu, 29 Mar 2012 07:21:11 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Rv1++viFC7EBfgJEdvu4gLbeR4rmyb@postini.com; Thu, 29 Mar 2012 07:21:14 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 07:20:49 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q2TEKn145454; Thu, 29 Mar 2012 07:20:49 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q2TEL9WW062433; Thu, 29 Mar 2012 10:21:10 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201203291421.q2TEL9WW062433@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20120329.151024.231403729.mbj@tail-f.com> Date: Thu, 29 Mar 2012 10:21:09 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:21:16 -0000 Martin Bjorklund writes: >So do you think the same should be done here? > > /routing/ > /logical-router/ Yup, that's what I'd suggest. We actually use the term "logical systems" because they can do much more that just routing (L2, firewall, etc). We also have "routing-instances" which are multiple protocol instances running inside a system or logical system: /protocols/bgp /routing-instances/protocols/bgp /logical-systems/routing-instances/protocols/bgp Add in the config groups hierarchy and some wildcard matches and you've got a party, dude ;^) Thanks, Phil http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/routing-instances-configuration-guidelines.html http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/overview_1.html#id-10523666 From lhotka@cesnet.cz Thu Mar 29 09:35:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D933E21F890F for ; Thu, 29 Mar 2012 09:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et8n-CWGhS-C for ; Thu, 29 Mar 2012 09:35:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD1B21F890E for ; Thu, 29 Mar 2012 09:35:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CDDF354025C; Thu, 29 Mar 2012 18:35:34 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFZbjG666XqU; Thu, 29 Mar 2012 18:35:28 +0200 (CEST) Received: from localhost (ATuileries-151-1-32-98.w82-123.abo.wanadoo.fr [82.123.248.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B93A254015C; Thu, 29 Mar 2012 18:35:27 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20120329.084030.108113872.mbj@tail-f.com> References: <20120329.084030.108113872.mbj@tail-f.com> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Thu, 29 Mar 2012 18:35:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:35:47 -0000 Hi Martin, thanks for the review. On Thu, 29 Mar 2012 08:40:30 +0200 (CEST), Martin Bjorklund wrote: > Hi, > > Here are my comments on draft-ietf-netmod-routing-cfg-02. > > o 4.1 > > Each router instance in the core routing data model represents a > (logical) router whose configuration and operation is independent > of other router instances. > > Why do we need this extra list (/routing/router)? Can you > examplify when more than one list entry would be used? I will react separately to this, also taking into account Phil's comments. > > > o 4.1 > > Logical network interfaces must be assigned to a router instance > > What is a "Logical network interface"? > draft-ietf-netmod-interfaces-cfg does not use this term. OK, I will change it to "network layer interface". > > o 4.2 > > s/destination-prefix/dest-prefix/ > > OR the other way around in the data model. I will use "destination-prefix" everywhere. > > > o 4.3 > > You say that at least two routing tables MUST be present. > > Can we change the name of a routing table to be: > > type union { > type enumeration { > enum fib; > enum main; > } > type string; > } > > This makes it clear which table is the fib and which is main. Unfortunately, this cannot be done because the pair of routing tables must be available for each supported address family - see sec. 4.3. > > Also, on my linux box, I can see the FIB, but what about main? Is > it always present? I assume that at least one routing table except FIB must be present because FIB only contains active routes. Otherwise there is nothing magical on the main table. The output of "ip route" on Linux is in fact a view of the main routing table because it can contain multiple routes for the same destination, e.g. with different metrics. > > > o 4.4 > > Each routing protocol instance is connected to exactly one > routing table. > > Where is this "exactly one" property in the data model? > "connected-routing-tables" has a list, so its seems a routing > protocol can be connected to 0 or more tables? Yup, I have to correct this in the text. A routing protocol may work with multiple address families, so it is connected to one table for each address family. This is enforced by the 'must' statement under "connected-routing-tables". > > > o 4.4 > > By default, every routing protocol instance SHOULD be connected > to the main routing table. > > I do not understand this sentence. What does it mean in terms of > the configuration? I have to add "... for each address family supported by the protocol." In terms of configuration it means that a protocol that is IPv4-only should have the list preconfigured as follows: main-ipV4-unicast As it is not possible to define default list contents in the data model, I have to assume that this is somehow factory-configured but can be changed. The "SHOULD" means that an implementation may do it differently if necessary. > > > o 4.4 > > Every router instance MUST contain exactly one instance of the > "direct" pseudo-protocol. > > What does this mean? This means that the "direct" protocol must be present, and only in one instance, in order to supply a direct route for each interface assigned to the router. It doesn't mean though that "direct" must appear in the configuration. > > > o 4.4.1 > > s/It is recommended/It is RECOMMENDED/ OK. > > o leaf cur-hop-limit { > type uint8; > default "64"; > > Is this default really correct? It doesn't match the text: > > The default should be set to the value specified in IANA > Assigned Numbers that was in effect at the time of > implementation. IANA document http://www.iana.org/assignments/ip-parameters says: "The current recommended default time to live (TTL) for the Internet Protocol (IP) is 64 [RFC791, RFC1122]." Lada > > I suggest you remove the default statement, and change the text to > something like > > If not explicitly configured, the value to be used in > the Cur Hop Limit field should be the value specified in IANA > Assigned Numbers that was in effect at the time of > implementation. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Mar 29 09:41:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8B21F84EB for ; Thu, 29 Mar 2012 09:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiQdfukbqHtF for ; Thu, 29 Mar 2012 09:41:05 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 75A4221F84FB for ; Thu, 29 Mar 2012 09:40:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6A8F754025C; Thu, 29 Mar 2012 18:40:58 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icp7ZLZfq+AF; Thu, 29 Mar 2012 18:40:52 +0200 (CEST) Received: from localhost (ATuileries-151-1-32-98.w82-123.abo.wanadoo.fr [82.123.248.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BC66D54015C; Thu, 29 Mar 2012 18:40:51 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer , Martin Bjorklund In-Reply-To: <201203291134.q2TBYcIZ061366@idle.juniper.net> References: <201203291134.q2TBYcIZ061366@idle.juniper.net> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org Date: Thu, 29 Mar 2012 18:40:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:41:06 -0000 On Thu, 29 Mar 2012 07:34:38 -0400, Phil Shafer wrote: > Martin Bjorklund writes: > >o 4.1 > > Each router instance in the core routing data model represents a > > (logical) router whose configuration and operation is independent > > of other router instances. > > > > Why do we need this extra list (/routing/router)? Can you > > examplify when more than one list entry would be used? > > LRs are independent of each other, but must exist in the > configuration of the full device. > > >o 4.2 > > s/destination-prefix/dest-prefix/ > > OR the other way around in the data model. > > Other way please. Full words are so much easy to standardize on. OK. > > > Also, on my linux box, I can see the FIB, but what about main? Is > > it always present? > > No. The FIB can be built from a set of routing tables that > are protocol-specific (inet, inet6, etc) where no specific > one can be called "main" (without upsetting the v6 folks ;^). Yes, a router implementing this module can do the same. > > If you keep it, "rib" might be a better name than "main". I am afraid this could start a new terminology discussion. > > Also there is a lot of information in the other routing tables > that isn't needed in the FIB. Yup, maybe I should make it more clear that the FIB is different from other routing tables. Lada > > >o 4.4 > > > > Every router instance MUST contain exactly one instance of the > > "direct" pseudo-protocol. > > > > What does this mean? > > I think this means routers without real interfaces are not > interesting. And while that may be true, interfaces can > appear and disappear (hot plug), so saying that I MUST > have one is not good. > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@cesnet.cz Thu Mar 29 09:54:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFD621E809E for ; Thu, 29 Mar 2012 09:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NEWDVpuC4UT for ; Thu, 29 Mar 2012 09:54:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4171A21E8055 for ; Thu, 29 Mar 2012 09:54:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 61C6254025C; Thu, 29 Mar 2012 18:54:44 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJZk4aqw0vnz; Thu, 29 Mar 2012 18:54:40 +0200 (CEST) Received: from localhost (ATuileries-151-1-32-98.w82-123.abo.wanadoo.fr [82.123.248.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CFF8254015C; Thu, 29 Mar 2012 18:54:39 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , phil@juniper.net In-Reply-To: <20120329.151024.231403729.mbj@tail-f.com> References: <20120329.141159.492740978.mbj@tail-f.com> <201203291307.q2TD7Ax1061867@idle.juniper.net> <20120329.151024.231403729.mbj@tail-f.com> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Martin Bjorklund , phil@juniper.net, netmod@ietf.org Date: Thu, 29 Mar 2012 18:54:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:54:46 -0000 On Thu, 29 Mar 2012 15:10:24 +0200 (CEST), Martin Bjorklund wrote: > Phil Shafer wrote: > > Martin Bjorklund writes: > > >I guess my concern is if this concept is similiar enough in different > > >vendors' routers that it make sense to standardize it like this. A > > >device that do not support multiple LRs is still required to have this > > >extra layer. > > > > We put LRs in a distinct container, since the base device > > has functionality outside the LR. You should not few the > > base device as a "special" LR. > > So do you think the same should be done here? > > /routing/ > /logical-router/ This means that the common stuff would be duplicated, although the duplication can be minimalized through the use of groupings. But also remember that most of the contents will appear here via augments from other modules, which means that the augmenting modules will actually have to define two augments: one for and another for . Another possibility is to introduce a new leaf specifying a router type (at least "base" versus "logical") and the difference of and would be conditional. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Fri Mar 30 01:19:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221F721F8822 for ; Fri, 30 Mar 2012 01:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQpzSXRCHZHU for ; Fri, 30 Mar 2012 01:19:44 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD9221F8820 for ; Fri, 30 Mar 2012 01:19:43 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr10.btconnect.com with SMTP id GVD33830; Fri, 30 Mar 2012 09:19:34 +0100 (BST) Message-ID: <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Martin Bjorklund" References: <20120329.084030.108113872.mbj@tail-f.com><201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> Date: Fri, 30 Mar 2012 09:18:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F756C96.0013, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.30.73315:17:7.944, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4F756C96.013B,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:19:45 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Thursday, March 29, 2012 2:11 PM > Phil Shafer wrote: > > Martin Bjorklund writes: > > >o 4.1 > > > Each router instance in the core routing data model represents a > > > (logical) router whose configuration and operation is independent > > > of other router instances. > > > > > > Why do we need this extra list (/routing/router)? Can you > > > examplify when more than one list entry would be used? > > > > LRs are independent of each other, but must exist in the > > configuration of the full device. > > I guess my concern is if this concept is similiar enough in different > vendors' routers that it make sense to standardize it like this. A > device that do not support multiple LRs is still required to have this > extra layer. Martin I was asked in 2002 if I knew of any routers which implemented multiple instances of BGP. I kept the e-mail, and for over five years, the answer was no; and even now, I suspect it remains no for almost all routers, Juniper being an - the? - exception - as is the case with many things, their routers having the most capabilities. Multi-instance OSPF is commoner, as I assume is multi-instance IS-IS, but the vast mass of routers have a single logical router with a single instance of some of OSPF, BGP, EIGRP, RIP etc. The art is to make that simple and clear to configure even when the model allows for the Junipers of this world. Tom Petch > > Also, if this data model has this extra list on the top, do we need to > do the same in other data models? > > > >o 4.4 > > > > > > Every router instance MUST contain exactly one instance of the > > > "direct" pseudo-protocol. > > > > > > What does this mean? > > > > I think this means routers without real interfaces are not > > interesting. And while that may be true, interfaces can > > appear and disappear (hot plug), so saying that I MUST > > have one is not good. > > Ok. > > I meant what does this "MUST" mean for an implementation? > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From ietfc@btconnect.com Fri Mar 30 01:27:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7121C21F85FD for ; Fri, 30 Mar 2012 01:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHdSpL41pf4w for ; Fri, 30 Mar 2012 01:27:37 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE1E21F85F6 for ; Fri, 30 Mar 2012 01:27:37 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr07.btconnect.com with SMTP id GWL97585; Fri, 30 Mar 2012 09:27:31 +0100 (BST) Message-ID: <010801cd0e46$66341000$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ladislav Lhotka" , "Phil Shafer" , "Martin Bjorklund" References: <201203291134.q2TBYcIZ061366@idle.juniper.net> Date: Fri, 30 Mar 2012 09:26:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F756E72.00FF, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.30.73315:17:7.944, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_24, ECARD_WORD, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4F756E73.00D9,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:27:38 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Phil Shafer" ; "Martin Bjorklund" Cc: Sent: Thursday, March 29, 2012 6:40 PM > On Thu, 29 Mar 2012 07:34:38 -0400, Phil Shafer wrote: > > Martin Bjorklund writes: > > >o 4.1 > > > Each router instance in the core routing data model represents a > > > (logical) router whose configuration and operation is independent > > > of other router instances. > > > > > > Why do we need this extra list (/routing/router)? Can you > > > examplify when more than one list entry would be used? > > > > LRs are independent of each other, but must exist in the > > configuration of the full device. > > > > >o 4.2 > > > s/destination-prefix/dest-prefix/ > > > OR the other way around in the data model. > > > > Other way please. Full words are so much easy to standardize on. > > OK. > > > > Also, on my linux box, I can see the FIB, but what about main? Is > > > it always present? > > > > No. The FIB can be built from a set of routing tables that > > are protocol-specific (inet, inet6, etc) where no specific > > one can be called "main" (without upsetting the v6 folks ;^). > > Yes, a router implementing this module can do the same. > > > > > If you keep it, "rib" might be a better name than "main". > > I am afraid this could start a new terminology discussion. Lada Yes, I was about to say that I do not see the term 'main' in use but I do see widespread use of RIB in contrast to FIB. RIB is built into the logic of the specification of BGP and I see it applied in more general discussions of routing, even when the protocol has its own terminology, as when, for example, OSPF uses Link State Data Base. RIP has a 'RIB', else it could not do split horizon with poison reverse, but its existence is usually kept secret, not something I have ever understood. FIB does sometimes get subdivided as when it gets downloaded to a line card, with different line cards having different parts of the routing table. Tom Petch > > > > Also there is a lot of information in the other routing tables > > that isn't needed in the FIB. > > Yup, maybe I should make it more clear that the FIB is different from other routing tables. > > Lada > > > > > >o 4.4 > > > > > > Every router instance MUST contain exactly one instance of the > > > "direct" pseudo-protocol. > > > > > > What does this mean? > > > > I think this means routers without real interfaces are not > > interesting. And while that may be true, interfaces can > > appear and disappear (hot plug), so saying that I MUST > > have one is not good. > > > > Thanks, > > Phil > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From andrewmcgr@gmail.com Fri Mar 30 01:32:20 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBB621F86EF for ; Fri, 30 Mar 2012 01:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NDvhqsXS4rx for ; Fri, 30 Mar 2012 01:32:18 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 684E121F86F9 for ; Fri, 30 Mar 2012 01:32:18 -0700 (PDT) Received: by werb10 with SMTP id b10so264693wer.31 for ; Fri, 30 Mar 2012 01:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=9vCIoJPjgP+13QPNKmTKUKMqqvAAgQrlYNtf1hEjn0A=; b=Wkggmi36uiV2144jILbx7FbWAF9c0w66XoOSp68Z6aXkuLF5RDAYD4Q0wR9N8J/i6D 7Dm1586k3pAURtW0YGguTo3ibpip6metIoiskyHModgysROxEZYnPRxjQOikVZ5PRlK3 vLtmXAnfP6NGX8nCdhZLwCfn96xreOKS3Vn7lf9SkYaNSdSzlrqaUuoXICvWSBDLr1qZ Wg6L4GMPPUcKK/c6IWNKoLVobn2Da2iA/NpVXN4e2XbhyvAN9lrOCNOzwhm53UvSXN2G +NNKe+O1DpDGopBUk0Q25CDXx6+vcnJb1bcjJiSPsA5iPZslVoLZkQm3DR0OW8tntivG +rDw== Received: by 10.180.107.101 with SMTP id hb5mr4840655wib.3.1333096337423; Fri, 30 Mar 2012 01:32:17 -0700 (PDT) Received: from dhcp-63b7.meeting.ietf.org (dhcp-63b7.meeting.ietf.org. [130.129.99.183]) by mx.google.com with ESMTPS id j3sm7510067wiw.1.2012.03.30.01.32.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 01:32:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_7100FE31-E09F-40FC-89E6-9A311DC21F2F"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew McGregor X-Priority: 3 In-Reply-To: <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> Date: Fri, 30 Mar 2012 10:32:14 +0200 Message-Id: References: <20120329.084030.108113872.mbj@tail-f.com><201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1257) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:32:20 -0000 --Apple-Mail=_7100FE31-E09F-40FC-89E6-9A311DC21F2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Allied Telesis switches support multiple instances (or effectively = multiple instances) of all the supported unicast routing protocols (in = the current version, BGP, OSPF and RIP), in the presence of virtual = routers. See the howto document here: = http://alliedtelesis.com.au/userfiles/file/howto_aw-_config_VRF_Lite_RevC.= pdf The model in the draft is similar enough to how the routing works in our = switches that it works for us. It also works for the full generality of = the linux kernel's network namespace feature, which is far more = complicated than VRF-lite. I think it's general enough to work for almost any situation, and simple = enough not to be unduly confusing. Andrew On 30/03/2012, at 9:18 AM, t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, March 29, 2012 2:11 PM >> Phil Shafer wrote: >>> Martin Bjorklund writes: >>>> o 4.1 >>>> Each router instance in the core routing data model represents a >>>> (logical) router whose configuration and operation is = independent >>>> of other router instances. >>>>=20 >>>> Why do we need this extra list (/routing/router)? Can you >>>> examplify when more than one list entry would be used? >>>=20 >>> LRs are independent of each other, but must exist in the >>> configuration of the full device. >>=20 >> I guess my concern is if this concept is similiar enough in different >> vendors' routers that it make sense to standardize it like this. A >> device that do not support multiple LRs is still required to have = this >> extra layer. >=20 > Martin >=20 > I was asked in 2002 if I knew of any routers which implemented = multiple > instances of BGP. I kept the e-mail, and for over five years, the = answer was > no; and even now, I suspect it remains no for almost all routers, = Juniper being > an - the? - exception - as is the case with many things, their routers = having > the most capabilities. >=20 > Multi-instance OSPF is commoner, as I assume is multi-instance IS-IS, = but the > vast mass of routers have a single logical router with a single = instance of some > of OSPF, BGP, EIGRP, RIP etc. >=20 > The art is to make that simple and clear to configure even when the = model allows > for the Junipers of this world. >=20 > Tom Petch >=20 >>=20 >> Also, if this data model has this extra list on the top, do we need = to >> do the same in other data models? >>=20 >>>> o 4.4 >>>>=20 >>>> Every router instance MUST contain exactly one instance of the >>>> "direct" pseudo-protocol. >>>>=20 >>>> What does this mean? >>>=20 >>> I think this means routers without real interfaces are not >>> interesting. And while that may be true, interfaces can >>> appear and disappear (hot plug), so saying that I MUST >>> have one is not good. >>=20 >> Ok. >>=20 >> I meant what does this "MUST" mean for an implementation? >>=20 >>=20 >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_7100FE31-E09F-40FC-89E6-9A311DC21F2F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLjCCBSow ggQSoAMCAQICEQDMQ2ZKvgsUYA5oQg5SjWfVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMTAwMTAwMDAwMFoXDTEyMDkzMDIzNTk1OVowJTEj MCEGCSqGSIb3DQEJARYUYW5kcmV3bWNnckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+buTRxzSXTQmMyUqaokLJit3xU5WVudxHijhKbGRSTgJ867L/v8+rNhSoFwCV MdKIu/M7apWgGkkA+MT/LjDFj63jLT+4nTTLIojXZdoezbpp/rQ2ViSbi54AjhZBQ5X+yH2xcXmG KpDhZjeZC1bvKNvBtdOHCAcrx1Ys1BNj+AhwridEX/KD0cq5xSsJhjDggF6XSUOsaiqBHR6fiQMi 7gH8EuFBh83oklb/pdreg1fQ7gKJk/Me/atIbE1gtbIR88oaCtXoHfZxgkFwagwMtBHdkxN+wcZy 9xx78el9Lxrjx2nMq50hRlj/bqg/m4rSox7//DKfx7bfKNZAiSMDAgMBAAGjggHkMIIB4DAfBgNV HSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUXOXqNkq6sNbrD8B41dPko8Gs JucwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysG AQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRh bmRyZXdtY2dyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAgmf81vnsAnbcmIAyyqvEKxAK jRHerfreN10DK1ISkUJ//U4uffQV8sAGDtyIErzVFsW6NYRmFCMSE20M1ffbFpWUmXCtm/YTlkf1 5STVjTMNshDzMDhpjx99Z2J5RBJPZpXjwmpQnfKwB7zft9TcUSIb9FvZm33EKdF/XlS12U4Q9fsj 2shZf88RituX2+fCWfHoTWiFEhFUkLRtWf1YpgHpEXr82nqROxs/aWNlqtLnwTTu2ULr/WpUaRDs kom8gFZkMgw5kRfLpSXRrCFSORsZzkH2ooRxaJY7wMwZaCUS1am9DuwVy7gehoc3ZsjsDkMObZeu kx7Cg7GxIkgo+zGCA64wggOqAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzENmSr4LFGAOaEIOUo1n1TAJBgUrDgMCGgUAoIIB2TAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMzAwODMyMTRaMCMGCSqGSIb3DQEJBDEWBBRqpkJx DoChFfyTIdCL712PWVYboTCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAzENmSr4LFGAOaEIOUo1n1TCBvAYLKoZIhvcNAQkQAgsxgayggakw gZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDMQ2ZKvgsUYA5oQg5SjWfVMA0G CSqGSIb3DQEBAQUABIIBADYxhCgwqhxAM9k25ggniyBbp8k26QNbHgAV7At79+n/Q0BLclkbO1A0 2wKgTEgXGAMT/oNIRc1WUDwOQ/nMVepjF1H1k3Mqwu2FzoHuLrcF/H9tvpimoxQzqA0gJPp42quX FHt515FaIu8ioZk+J6HEUHQmjvVeMIPeMNvo3PoXuY+mdHfGJwAI8j/AbHJCLV8IBMTARMCNjvoQ YuxrH18hthtrg7vZms1evzBEjEFHB9sKt0WOyy8bNFVG7BSAGo7pm4Ozd+mGEWVImKkQoRqRKgb+ JEPoJ6rssSr9g8Sb61RlbdXMIR9CTjcnz72Dz99gFsWP3Mg55N3ymE0iDNsAAAAAAAA= --Apple-Mail=_7100FE31-E09F-40FC-89E6-9A311DC21F2F-- From lhotka@cesnet.cz Fri Mar 30 02:44:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DA221F8875 for ; Fri, 30 Mar 2012 02:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V07tXblqppUC for ; Fri, 30 Mar 2012 02:44:05 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57E21F8874 for ; Fri, 30 Mar 2012 02:44:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 72509540704; Fri, 30 Mar 2012 11:44:02 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI5ilXHexZlX; Fri, 30 Mar 2012 11:43:57 +0200 (CEST) Received: from localhost (dhcp-1072.meeting.ietf.org [130.129.16.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C92115400F1; Fri, 30 Mar 2012 11:43:56 +0200 (CEST) From: Ladislav Lhotka To: Andrew McGregor , "t.petch" In-Reply-To: References: <20120329.084030.108113872.mbj@tail-f.com><201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Andrew McGregor , "t.petch" , netmod@ietf.org Date: Fri, 30 Mar 2012 11:43:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:44:06 -0000 On Fri, 30 Mar 2012 10:32:14 +0200, Andrew McGregor wrote: > Allied Telesis switches support multiple instances (or effectively multiple instances) of all the supported unicast routing protocols (in the current version, BGP, OSPF and RIP), in the presence of virtual routers. See the howto document here: http://alliedtelesis.com.au/userfiles/file/howto_aw-_config_VRF_Lite_RevC.pdf > > The model in the draft is similar enough to how the routing works in our switches that it works for us. It also works for the full generality of the linux kernel's network namespace feature, which is far more complicated than VRF-lite. > > I think it's general enough to work for almost any situation, and simple enough not to be unduly confusing. This is encouraging to hear. I think the answer to the question whether to support multiple logical routers in the routing data model should be a resounding yes. So we just have to decide what is the best way to do it. In my opinion, the existing schema is satisfactory and certainly not limited to a JUNOS-like configuration of logical routers. The flip side is that there is an extra container ("router") which has to be used even in cases where there are no logical routers. I consider this drawback to be relatively minor. Lada > > Andrew > > On 30/03/2012, at 9:18 AM, t.petch wrote: > > > ----- Original Message ----- > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Thursday, March 29, 2012 2:11 PM > >> Phil Shafer wrote: > >>> Martin Bjorklund writes: > >>>> o 4.1 > >>>> Each router instance in the core routing data model represents a > >>>> (logical) router whose configuration and operation is independent > >>>> of other router instances. > >>>> > >>>> Why do we need this extra list (/routing/router)? Can you > >>>> examplify when more than one list entry would be used? > >>> > >>> LRs are independent of each other, but must exist in the > >>> configuration of the full device. > >> > >> I guess my concern is if this concept is similiar enough in different > >> vendors' routers that it make sense to standardize it like this. A > >> device that do not support multiple LRs is still required to have this > >> extra layer. > > > > Martin > > > > I was asked in 2002 if I knew of any routers which implemented multiple > > instances of BGP. I kept the e-mail, and for over five years, the answer was > > no; and even now, I suspect it remains no for almost all routers, Juniper being > > an - the? - exception - as is the case with many things, their routers having > > the most capabilities. > > > > Multi-instance OSPF is commoner, as I assume is multi-instance IS-IS, but the > > vast mass of routers have a single logical router with a single instance of some > > of OSPF, BGP, EIGRP, RIP etc. > > > > The art is to make that simple and clear to configure even when the model allows > > for the Junipers of this world. > > > > Tom Petch > > > >> > >> Also, if this data model has this extra list on the top, do we need to > >> do the same in other data models? > >> > >>>> o 4.4 > >>>> > >>>> Every router instance MUST contain exactly one instance of the > >>>> "direct" pseudo-protocol. > >>>> > >>>> What does this mean? > >>> > >>> I think this means routers without real interfaces are not > >>> interesting. And while that may be true, interfaces can > >>> appear and disappear (hot plug), so saying that I MUST > >>> have one is not good. > >> > >> Ok. > >> > >> I meant what does this "MUST" mean for an implementation? > >> > >> > >> /martin > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > Attachment: smime.p7s (application/pkcs7-signature) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Mar 30 03:27:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C0121F869D for ; Fri, 30 Mar 2012 03:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IUjFpvD0IR2 for ; Fri, 30 Mar 2012 03:27:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 57B6D21F869C for ; Fri, 30 Mar 2012 03:27:07 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2B5620C06; Fri, 30 Mar 2012 12:27:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4OWITBtbXRtj; Fri, 30 Mar 2012 12:27:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 407B020C03; Fri, 30 Mar 2012 12:27:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 870C91E25E28; Fri, 30 Mar 2012 12:27:06 +0200 (CEST) Date: Fri, 30 Mar 2012 12:27:06 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120330102706.GA65422@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] common yang data types - 6021bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:27:08 -0000 Hi, I have been working with Martin on some of the data models and it turns out there are some types that we forgot to define when RFC 6021 was created. The most visible example is a hex-string data type. While we could put missing type definitions in more or less random places, it seems a cleaner approach would be to start a 6021bis where we add more common types and which we submit for publication about the time we are done with all the other modules. (Since the 6021bis will only contain some additional type definitions, I assume it will be easy to progress it through the IESG.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Fri Mar 30 03:38:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BF21F8867 for ; Fri, 30 Mar 2012 03:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKLRICT2+w+x for ; Fri, 30 Mar 2012 03:38:20 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id E39E921F8863 for ; Fri, 30 Mar 2012 03:38:19 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr08.btconnect.com with SMTP id GUV16908; Fri, 30 Mar 2012 11:38:14 +0100 (BST) Message-ID: <004701cd0e58$a935d200$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ladislav Lhotka" , "Andrew McGregor" References: <20120329.084030.108113872.mbj@tail-f.com><201203291134.q2TBYcIZ061366@idle.juniper.net> <20120329.141159.492740978.mbj@tail-f.com> <00fc01cd0e45$49e83760$4001a8c0@gateway.2wire.net> Date: Fri, 30 Mar 2012 11:36:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F758D16.0043, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.30.101218:17:7.944, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __STOCK_PHRASE_24, __CP_URI_IN_BODY, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4F758D16.01C9,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:38:21 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Andrew McGregor" ; "t.petch" Cc: Sent: Friday, March 30, 2012 11:43 AM > On Fri, 30 Mar 2012 10:32:14 +0200, Andrew McGregor wrote: > > Allied Telesis switches support multiple instances (or effectively multiple instances) of all the supported unicast routing protocols (in the current version, BGP, OSPF and RIP), in the presence of virtual routers. See the howto document here: http://alliedtelesis.com.au/userfiles/file/howto_aw-_config_VRF_Lite_RevC.pdf > > > > The model in the draft is similar enough to how the routing works in our switches that it works for us. It also works for the full generality of the linux kernel's network namespace feature, which is far more complicated than VRF-lite. > > > > I think it's general enough to work for almost any situation, and simple enough not to be unduly confusing. > > This is encouraging to hear. > > I think the answer to the question whether to support multiple logical routers in the routing data model should be a resounding yes. So we just have to decide what is the best way to do it. In my opinion, the existing schema is satisfactory and certainly not limited to a JUNOS-like configuration of logical routers. The flip side is that there is an extra container ("router") which has to be used even in cases where there are no logical routers. I consider this drawback to be relatively minor. Lada I agree that that is a minor drawback but the one that Martin raised might be greater, of what attributes are regarded as part of the box as a whole and what are part of each logical router. Does everyone who has logical routers take the same approach? Looking at the document that Andrew referenced - good to have that - some things can be specific to a logical router - IP addresses, OSPF, Telnet client - while others cannot - SNMP, NTP, DHCP servers. I doubt if that approach would apply to other boxes. If, as I suspect, it is a top end box feature, then the configuration needs not to add too much complexity to the generic case. Tom Petch > Lada > > > > > Andrew > > > > On 30/03/2012, at 9:18 AM, t.petch wrote: > > > > > ----- Original Message ----- > > > From: "Martin Bjorklund" > > > To: > > > Cc: > > > Sent: Thursday, March 29, 2012 2:11 PM > > >> Phil Shafer wrote: > > >>> Martin Bjorklund writes: > > >>>> o 4.1 > > >>>> Each router instance in the core routing data model represents a > > >>>> (logical) router whose configuration and operation is independent > > >>>> of other router instances. > > >>>> > > >>>> Why do we need this extra list (/routing/router)? Can you > > >>>> examplify when more than one list entry would be used? > > >>> > > >>> LRs are independent of each other, but must exist in the > > >>> configuration of the full device. > > >> > > >> I guess my concern is if this concept is similiar enough in different > > >> vendors' routers that it make sense to standardize it like this. A > > >> device that do not support multiple LRs is still required to have this > > >> extra layer. > > > > > > Martin > > > > > > I was asked in 2002 if I knew of any routers which implemented multiple > > > instances of BGP. I kept the e-mail, and for over five years, the answer was > > > no; and even now, I suspect it remains no for almost all routers, Juniper being > > > an - the? - exception - as is the case with many things, their routers having > > > the most capabilities. > > > > > > Multi-instance OSPF is commoner, as I assume is multi-instance IS-IS, but the > > > vast mass of routers have a single logical router with a single instance of some > > > of OSPF, BGP, EIGRP, RIP etc. > > > > > > The art is to make that simple and clear to configure even when the model allows > > > for the Junipers of this world. > > > > > > Tom Petch > > > > > >> > > >> Also, if this data model has this extra list on the top, do we need to > > >> do the same in other data models? > > >> > > >>>> o 4.4 > > >>>> > > >>>> Every router instance MUST contain exactly one instance of the > > >>>> "direct" pseudo-protocol. > > >>>> > > >>>> What does this mean? > > >>> > > >>> I think this means routers without real interfaces are not > > >>> interesting. And while that may be true, interfaces can > > >>> appear and disappear (hot plug), so saying that I MUST > > >>> have one is not good. > > >> > > >> Ok. > > >> > > >> I meant what does this "MUST" mean for an implementation? > > >> > > >> > > >> /martin > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > >> > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > Attachment: smime.p7s (application/pkcs7-signature) > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > From per@tail-f.com Fri Mar 30 06:39:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3552E21F86B0 for ; Fri, 30 Mar 2012 06:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FjsZa90Jsl9 for ; Fri, 30 Mar 2012 06:39:58 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5988A21F8682 for ; Fri, 30 Mar 2012 06:39:58 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 67C2712008BF for ; Fri, 30 Mar 2012 15:39:56 +0200 (CEST) Message-ID: <4F75B7AC.2070206@tail-f.com> Date: Fri, 30 Mar 2012 15:39:56 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7 MIME-Version: 1.0 To: netmod@ietf.org References: <6DD5C845-4B7E-4C12-8587-79A27DF9212E@gmail.com> In-Reply-To: <6DD5C845-4B7E-4C12-8587-79A27DF9212E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [netmod] draft-ietf-netmod-system-mgmt NTP server issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:39:59 -0000 On 2012-03-27 14:23, Andrew McGregor wrote: > The present NTP configuration tree in the draft looks like this: > > +--rw system > ... > +--rw ntp > +--rw use-ntp? boolean > +--rw ntp-server [address] > +--rw address inet:host > +--rw enabled boolean > > This does not quite line up with the way the protocol actually works. > The NTP protocol determines the server priority itself, it does not > support a priority list per se, I agree, though I was at first confused since your tree snippet did not show the problem. I.e. the problem is that the list is ordered-by user, with "The user specified order indicates the server priority" as part of the description. The list order should not be significant, a standards-compliant NTP client can't obey such a configuration. > although it has several per-server options that bias the selection > process. There are also several kinds of association. > > Thus the tree should be something more like: > > +--rw system > ... > +--rw ntp > +--rw use-ntp? boolean > +--rw ntp-server [address] > +--rw type ntp-association-type > +--rw address inet:host > +--rw enabled boolean > +--rw iburst boolean > +--rw prefer boolean > +--rw true boolean > > where ntp-association-type is an enum with values 'server' 'peer' or > 'pool' and the booleans iburst, noselect, prefer and true are as > defined by the NTP reference implementation. I guess the question here is wether this should be a model for a generic standard NTP client, or for the (so-called) reference implementation. Personally I think the only reasonable choice is the former, among other things there exists viable freely-available alternatives to the reference implementation, and vendors can presumably augment the model with proprietary knobs. I'm pretty sure that 'pool' and 'iburst', although useful and relevant here, are not part of the NTP standard, and I don't believe 'prefer' is either. The 'true' as a configuration option is unknown to me even for the reference implementation, but I may be missing it in the plethora of options. Traditionally the reference implementation uses "magic" 127.127.x.x addresses to indicate a reference clock. In any case I doubt that it is meaningful for this model to cover the configuration of reference clocks. The concept of 'server' and 'peer' association modes are part of the standard, and may be useful to be able to configure, the alternative being to have 'server' be implicit. I'm not sure that 'peer' has more merit than the possibility to configure broadcast/multicast client modes, though. Another viewpoint is that the model should also - or maybe instead - cover the configuration of a SNTP client, which may well be the only thing that many devices have. As far as the standard is concerned, a SNTP client has a single server - i.e. the obviously desirable possibility to have multiple servers for redundancy, and the manner in which they are selected/combined, is outside the standard. In this case the ordered-by user prioritized list in the current draft may make sense. I'm afraid I don't have good specific suggestions for alternate text at this point, just wanted to give another opinion... --Per Hedeland From jeffrey.K.lange@ge.com Fri Mar 30 06:46:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4EB21F86B7 for ; Fri, 30 Mar 2012 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JXQUnf0RioP for ; Fri, 30 Mar 2012 06:46:46 -0700 (PDT) Received: from exprod5og106.obsmtp.com (exprod5og106.obsmtp.com [64.18.0.182]) by ietfa.amsl.com (Postfix) with ESMTP id 956D421F856A for ; Fri, 30 Mar 2012 06:46:45 -0700 (PDT) Received: from alpmlip10.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob106.postini.com ([64.18.4.12]) with SMTP ID DSNKT3W5RYuAltzCDrXaz3j+pUkOAsNQMJv9@postini.com; Fri, 30 Mar 2012 06:46:45 PDT Received: from unknown (HELO alpmlef08.e2k.ad.ge.com) ([3.159.18.17]) by alpmlip10.e2k.ad.ge.com with ESMTP; 30 Mar 2012 09:45:51 -0400 Received: from LOUMLVEM02.e2k.ad.ge.com ([3.159.160.34]) by alpmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 09:45:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 09:45:49 -0400 Message-ID: In-Reply-To: <20120330102706.GA65422@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] common yang data types - 6021bis Thread-Index: Ac0OX6uhxdqvJQWhQ/KlnbkVPkPBegAGrfdA References: <20120330102706.GA65422@elstar.local> From: "Lange, Jeffrey K (GE Energy)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 30 Mar 2012 13:45:51.0665 (UTC) FILETIME=[6BD74A10:01CD0E7B] Subject: Re: [netmod] common yang data types - 6021bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:46:47 -0000 This isn't directly related to 6021 data types, more of an addition to = the ietf-inet-types , however one datatype that I found myself = implementing that would be nice to have as a standard type would be a = ip/prefix type that isn't limited to just specifying the prefix, There = is currently the ipv4-prefix and ipv6-prefix which has the exact syntax = that I'm looking for however the stipulation that all lower bits past = the prefix length means that I have to define my own data type to allow = someone to apply an IP address using the notation "dead:beef::1/64" Thanks, -Jeff Jeff Lange Lead Software Engineer GE Digital Energy - MDS =A0 T:=A0+1 585 242 8375 F: +1 585 241 5590 E:=A0Jeffrey.K.Lange@ge.com=20 www.GEDigitalEnergy.com =A0 175 Science Parkway Rochester, NY, 14620, USA -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Friday, March 30, 2012 6:27 AM To: netmod@ietf.org Subject: [netmod] common yang data types - 6021bis Hi, I have been working with Martin on some of the data models and it turns = out there are some types that we forgot to define when RFC 6021 was = created. The most visible example is a hex-string data type. While we could put missing type definitions in more or less random = places, it seems a cleaner approach would be to start a 6021bis where we = add more common types and which we submit for publication about the time = we are done with all the other modules. (Since the 6021bis will only = contain some additional type definitions, I assume it will be easy to = progress it through the IESG.) /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From jeffrey.K.lange@ge.com Fri Mar 30 06:55:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBFE21F86BB for ; Fri, 30 Mar 2012 06:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOy4w+-oZ3hM for ; Fri, 30 Mar 2012 06:55:37 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1540321F85EF for ; Fri, 30 Mar 2012 06:55:36 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKT3W7WPmLxHzo48tIklmrWR3AeopbrePI@postini.com; Fri, 30 Mar 2012 06:55:37 PDT Received: from unknown (HELO alpmlef01.e2k.ad.ge.com) ([3.159.18.10]) by alpmlip11.e2k.ad.ge.com with ESMTP; 30 Mar 2012 09:55:30 -0400 Received: from LOUMLVEM02.e2k.ad.ge.com ([3.159.160.34]) by alpmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 09:55:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 09:55:27 -0400 Message-ID: In-Reply-To: <4F75B7AC.2070206@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] draft-ietf-netmod-system-mgmt NTP server issues Thread-Index: Ac0Oepy6t0aBkwGmSmuLbWmUVreKwAAATA1w References: <6DD5C845-4B7E-4C12-8587-79A27DF9212E@gmail.com> <4F75B7AC.2070206@tail-f.com> From: "Lange, Jeffrey K (GE Energy)" To: "Per Hedeland" , X-OriginalArrivalTime: 30 Mar 2012 13:55:29.0861 (UTC) FILETIME=[C478FF50:01CD0E7C] Subject: Re: [netmod] draft-ietf-netmod-system-mgmt NTP server issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:55:38 -0000 I've just recently implemented this NTP model, and for what it's worth, = I used the following approach: - the first server in the user ordered list gets the preferred tag = applied to it - all entries have iburst applied to them I think that the iburst option is best left to the vendor to decide if = it should be applied or not.. we chose to use it for all entries. -Jeff Jeff Lange Lead Software Engineer GE Digital Energy - MDS =A0 T:=A0+1 585 242 8375 F: +1 585 241 5590 E:=A0Jeffrey.K.Lange@ge.com=20 www.GEDigitalEnergy.com =A0 175 Science Parkway Rochester, NY, 14620, USA -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf = Of Per Hedeland Sent: Friday, March 30, 2012 9:40 AM To: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt NTP server issues On 2012-03-27 14:23, Andrew McGregor wrote: > The present NTP configuration tree in the draft looks like this: >=20 > +--rw system > ... > +--rw ntp > +--rw use-ntp? boolean > +--rw ntp-server [address] > +--rw address inet:host > +--rw enabled boolean >=20 > This does not quite line up with the way the protocol actually works. > The NTP protocol determines the server priority itself, it does not=20 > support a priority list per se, I agree, though I was at first confused since your tree snippet did not = show the problem. I.e. the problem is that the list is ordered-by user, = with "The user specified order indicates the server priority" as part of = the description. The list order should not be significant, a = standards-compliant NTP client can't obey such a configuration. > although it has several per-server options that bias the selection=20 > process. There are also several kinds of association. >=20 > Thus the tree should be something more like: >=20 > +--rw system > ... > +--rw ntp > +--rw use-ntp? boolean > +--rw ntp-server [address] > +--rw type ntp-association-type > +--rw address inet:host > +--rw enabled boolean > +--rw iburst boolean > +--rw prefer boolean > +--rw true boolean >=20 > where ntp-association-type is an enum with values 'server' 'peer' or=20 > 'pool' and the booleans iburst, noselect, prefer and true are as=20 > defined by the NTP reference implementation. I guess the question here is wether this should be a model for a generic = standard NTP client, or for the (so-called) reference implementation. Personally I think the only reasonable choice is the former, among other = things there exists viable freely-available alternatives to the = reference implementation, and vendors can presumably augment the model = with proprietary knobs. I'm pretty sure that 'pool' and 'iburst', although useful and relevant = here, are not part of the NTP standard, and I don't believe 'prefer' is = either. The 'true' as a configuration option is unknown to me even for = the reference implementation, but I may be missing it in the plethora of = options. Traditionally the reference implementation uses "magic" 127.127.x.x addresses to indicate a reference clock. In any case I doubt = that it is meaningful for this model to cover the configuration of = reference clocks. The concept of 'server' and 'peer' association modes are part of the = standard, and may be useful to be able to configure, the alternative = being to have 'server' be implicit. I'm not sure that 'peer' has more = merit than the possibility to configure broadcast/multicast client = modes, though. Another viewpoint is that the model should also - or maybe instead - = cover the configuration of a SNTP client, which may well be the only = thing that many devices have. As far as the standard is concerned, a = SNTP client has a single server - i.e. the obviously desirable = possibility to have multiple servers for redundancy, and the manner in = which they are selected/combined, is outside the standard. In this case = the ordered-by user prioritized list in the current draft may make = sense. I'm afraid I don't have good specific suggestions for alternate text at = this point, just wanted to give another opinion... --Per Hedeland _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod