From nobody Tue Apr 1 16:52:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC991A002F for ; Tue, 1 Apr 2014 16:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6x9L42Y_Kk4 for ; Tue, 1 Apr 2014 16:52:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1854B1A001E for ; Tue, 1 Apr 2014 16:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15359; q=dns/txt; s=iport; t=1396396361; x=1397605961; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=crJSa4U/WDusEeBnNuxDwwed/lxkExxNagpDNDaRPJo=; b=Si6wPt4il3Xi6YiuYS5QJ6TDDTOCE3UPLYWR1s3LjAXLhiOccEccu/SD cFCg+FMk2dzOS8JJR1nuh/FAyZlorrA0sKNDvpPs719fjO693xmcCYt5h tsYAJk8MKfjgolqhH3KgZLBDJxVi2EjV7YsmNxZqQWxxZXlut9lZmNtWp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAMFPO1OtJV2Y/2dsb2JhbABZgkJEgRKsapZxgR4WdIIlAQIEgQsBCBEDAQIoORMBCQgCBAESh2UDEdA8F4xWggkYhDgBA4dmjwmBZ4dchRGFTIMwgis X-IronPort-AV: E=Sophos;i="4.97,776,1389744000"; d="scan'208,217";a="314259382" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 01 Apr 2014 23:52:40 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s31NqcpR030660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Apr 2014 23:52:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 18:52:37 -0500 From: "Lisa Huang (yihuan)" To: steve cheng , "netmod@ietf.org" Thread-Topic: [netmod] Suggestions for draft-huang-netmod-acl-03.txt Thread-Index: AQHPS3pijR1Q1sdM+0mIH/ybqDU4lJr9Um0A Date: Tue, 1 Apr 2014 23:52:37 +0000 Message-ID: In-Reply-To: <1396116711.53102.YahooMailNeo@web162504.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.165] Content-Type: multipart/alternative; boundary="_000_CF6080CB1185D7yihuanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gFTTI67UKmr5RdCNScopKNTN4nI Subject: Re: [netmod] Suggestions for draft-huang-netmod-acl-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 23:52:46 -0000 --_000_CF6080CB1185D7yihuanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Steve, Comments in line. --Lisa From: steve cheng > Reply-To: steve cheng > Date: Saturday, March 29, 2014 11:11 AM To: "netmod@ietf.org" > Subject: [netmod] Suggestions for draft-huang-netmod-acl-03.txt Hi Lisa/Alex/Andy, I saw current draft doesn't cover how SPF (ACL) is applied on an interface = or other client applications. Section 3.3.4 of the draft briefly covers how to apply SPF(ACL) to = interface and also gives an example of how to attach an SPF to an interfac= e. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We typically call these SPF(ACL) on an interface for packet filtering as Se= curity ACL. For example, interface foo SPF(ACL) bar ingress/egress Would it make sense to create a new draft? Yes. You could create a new module which augment interface module an= d add SPF(ACL) leaf list. Section 3.3.4 has an example of that. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Another kind of widely deployed SPF(ACL) is in other client applications. Q= oS, PBR, and routing protocols such as OSPF/BGP are some examples. * For QoS/PBR/other policy based applications, it's used for classifica= tion. For example QoS, * class foo: match SPF (ACL), * policy bar: match class foo, rate limiting * policy bar is applied on an interface ingress/egress One way is: Import stateless-pf { prefix "spf"; } =85 List class { Key "name"; Leaf "name" { =85 } Leaf-list match { type "spf:spf-ref"; } } * For routing protocols, it's used for route/prefix filtering (not pack= et filtering). prefix filter is different from access list since it has less filter= ing options and don't distinguish packet source and destination. Since both= filter has similarity, prefix filtering can reuse most of the grouping def= inition in SPF(ACL). * some other applications can simply use ACL (SPF) to filter out debugg= ing output. Is this the use case described in CLI? access-list 101 permit tcp any host 192.168.35.1 range 20 21 access-list 102 permit tcp host 192.168.35.1 any established interface ethernet 0 access-group 101 out access-group 102 in In this case, the configuration is a single unnamed ACE in ACL but ACE name= is a mandatory leaf in the draft. The implementation is not in scope of th= e draft, but one way to implement is to add an adapter of netconf engine an= d backend. The job of the adapter is to map name based ACE(netconf config) = to single no name ACE(system) back and forth. List access-group { Key "spf-name"; Leaf "spf-name" { type "spf:spf-ref"; } Leaf dirction { type enumeration { Enum "in"; Enum "out"; } } } Any suggestion on how to deal with them? cheers, Steve Cheng --_000_CF6080CB1185D7yihuanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Steve, Comments in line. --Lisa

From: steve cheng <scheng98_98@yahoo.com>
Reply-To: steve cheng <scheng98_98@yahoo.com>
Date: Saturday, March 29, 2014 11:1= 1 AM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] Suggestions for d= raft-huang-netmod-acl-03.txt

  • For QoS/PBR/other policy based applications, it's used for classificati= on. For example QoS,
    • class foo: match SPF (ACL),
    • policy bar: match class foo, rate limiting
    • policy bar is a= pplied on an interface ingress/egress
  • <Lisa>One way is:
    Import stateless-pf {
    prefix= "spf";
    }
    =85
    List class {
    Key &q= uot;name";
    Leaf &= quot;name" {
    =85
    }
    Leaf-l= ist match {
    type &= quot;spf:spf-ref";
    }
    }
  • For routing protocols, it's used for route/prefix filtering (not packet= filtering).
  • <Lisa> prefix filter is different from access list since it has = less filtering options and don't distinguish packet source and destination.= Since both filter has similarity, prefix filtering can reuse most of the g= rouping definition in SPF(ACL).
  • some other applications can simply use ACL (SPF) to filter out debuggin= g output.
  • <Lisa>Is this the use case described in CLI?
    access-list 101 permit tcp any ho=
    st 192.168.35.1 range 20 21
    access-list 102 permit tcp host 192.168.35.1 any estab=
    lished
    interface ethernet 0
    access-group 101 out
    access-group 102 in
    In this case, the configuration is a single unnamed AC=
    E in ACL but ACE name is a mandatory leaf in the draft. The imple=
    mentation is not in scope of the draft, but one way to implement is to add =
    an adapter of netconf engine and backend. The job of the adapter is to map =
    name based ACE(netconf config) to single no name ACE(system) back and forth=
    . 
    List access-group {
    Key "spf-name";
    L= eaf "spf-name" {
    type "spf:spf-ref";
    }
    Leaf  dirction {
    type enumeration {
    Enum "in";
    Enum "out";
    }
    }
    = }
    Any suggestion on how to deal with them?


    cheers,

    Steve Cheng


    --_000_CF6080CB1185D7yihuanciscocom_-- From nobody Tue Apr 1 19:57:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6583A1A00BB; Tue, 1 Apr 2014 19:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nu0EZf8ycVM; Tue, 1 Apr 2014 19:57:40 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A878C1A00BA; Tue, 1 Apr 2014 19:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3842; q=dns/txt; s=iport; t=1396407457; x=1397617057; h=from:to:subject:date:message-id:mime-version; bh=VHJu5v0zp2IkyLZ0szLVQryycztIHWyEOdXSNYSpCD0=; b=jgjFaNqywYtEQFUmDB+xp6pLrNfBci05D/YHytuOk4zTJGvSQscmcLHI YbZrPw65t6pPjA1OAk4yKjpV1zqiDGdido2hmv6BiVgeAhQvDAqx62ddg uWtVOW0EUCr1jmnCcSQr7icQTAA34dG2zGV/BJSaVVweV/InCNOGSJz/i w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAEF8O1OtJA2B/2dsb2JhbABZgkJEO1fDZYEfFnSCJwEELV4BDB5WJgEEARoBh3AN0C4Xjj+DXIEUBKsPgzCCKw X-IronPort-AV: E=Sophos; i="4.97,777,1389744000"; d="scan'208,217"; a="32155100" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 02 Apr 2014 02:57:36 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s322vZEl014567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 02:57:36 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 21:57:35 -0500 From: "Tissa Senevirathne (tsenevir)" To: "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVww== Date: Wed, 2 Apr 2014 02:57:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.164] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FdHb3NMeqCAWI5WuHB1BYJa7IM8 Subject: [netmod] YANG model for protocol independent OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 02:57:42 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All In the draft below we present YANG model to abstract protocol dependent asp= ects of OAM and create a unified OAM API set. In a nutshell, ping is ping a= nd traceroute is traceroute and so on. Protocol independent API 's allow us= ers to exercise these OAM tools in the same manner across different technol= ogies and allow to integrate to their operations platforms. Appreciate your time on reviewing and providing comments, both on API's and= YANG model as well as OAM framework in it self. http://www.ietf.org/id/draft-tissa-netmod-oam-00.txt Thanks Tissa --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    All

     

    In the draft below we present YANG model to abstract= protocol dependent aspects of OAM and create a unified OAM API set. In a n= utshell, ping is ping and traceroute is traceroute and so on. Protocol inde= pendent API ‘s allow users to exercise these OAM tools in the same manner across different technologies and allow= to integrate to their operations platforms.

     

    Appreciate your time on reviewing and providing comm= ents, both on API’s and YANG model as well as OAM framework in it sel= f.

     

    http://www.ietf.org/id/draft-tissa-netmod-oam-00.txt<= /o:p>

     

    Thanks

    Tissa

    --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_-- From nobody Tue Apr 1 21:17:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4721A0108; Tue, 1 Apr 2014 21:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.06 X-Spam-Level: X-Spam-Status: No, score=-7.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQTLPmWj_tqA; Tue, 1 Apr 2014 21:17:30 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4AC1A00F3; Tue, 1 Apr 2014 21:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17087; q=dns/txt; s=iport; t=1396412246; x=1397621846; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xWXJ7RvcF0N3JMtcWXFj31UtU/LN9QjMGl4pWG63fy8=; b=P97sM57NGxIYnJmU1RzFTF2nha0zuWthVdl/PbB04rsVmgIw9UEoijvI VA00S6HJ5Irhj1wyBgmSq37Ot1IG4nprqdypixOJbGL7V+C7HXmwtpEiV ig0f5qyY7CRhGUOCVzbnuJlotAiBduwzF/RlPDpS0/UEC5AONGs1rRXOG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAB6DO1OtJA2J/2dsb2JhbABZgkJEO1eDCsBbGYEGFnSCJQEBAQQtTBACAQYCEQQBAQsdBQICMBQJCAEBBAENBQgBh3ANkUScEgiiPxeOPxYbBgGCazmBFASrD4Mwgis X-IronPort-AV: E=Sophos; i="4.97,777,1389744000"; d="scan'208,217"; a="32171676" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 02 Apr 2014 04:17:26 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s324HPlb032517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 04:17:25 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 23:17:24 -0500 From: "Tissa Senevirathne (tsenevir)" To: Haoweiguo , "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVwwABSb29AAESopA= Date: Wed, 2 Apr 2014 04:17:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.164] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2f1ek98P2X8YvpKsXWqzVf4msu8 Cc: "trill@ietf.org" Subject: Re: [netmod] YANG model for protocol independent OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 04:17:33 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV2VpZ3VvDQoNClRoYW5rcyBmb3Igc29tZSB2ZXJ5IGdvb2Qgc2V0IG9mIHF1ZXN0aW9ucywg cGxlYXNlIHNlZSB0aGUgYW5zd2VycyBiZWxvdyBpbi1saW5lIHdpdGggW2Fuc3dlcl0NCg0KRnJv bTogSGFvd2VpZ3VvIFttYWlsdG86aGFvd2VpZ3VvQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAwMSwgMjAxNCA4OjUxIFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZp cik7IG1wbHNAaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmcNClN1Ympl Y3Q6ILTwuLQ6IFlBTkcgbW9kZWwgZm9yIHByb3RvY29sIGluZGVwZW5kZW50IE9BTQ0KDQoNCkhp IFRpc3NhLA0KDQpUaGFua3MgZm9yIHlvdXIgcHJlc2VudGluZyB0aGUgZGV0YWlsIFlhbmcgbW9k ZWwgb2YgVFJJTEwgT0FNLiBBZnRlciByZWFkIHRoZSBkcmFmdCwgaSBoYXZlIHNvbWUgY29tbWVu dHMgYW5kIHByb2JsZW1zIGFzIGZvbGxvd3MuDQoNCg0KDQoxLiBUaGVyZSBpcyBubyBNSVAgZGF0 YSBtb2RlbCBpbiB0aGlzIGRyYWZ0LCBpbiBUUklMTCBPQU0gRnJhbWV3b3JrIE1JUCBpcyBkZWZp bml0ZWx5IGRlZmluZWQgdG8gZmlsdGVyIE9BTSBwYWNrZXQgYmFzZWQgb24gTUlQIGxldmVsLg0K DQpbYW5zd2VyXSBJIGludGVudGlvbmFsbHkgc2tpcHBlZCB0aGlzIGZvciB0aGUgaW5pdGlhbCBy ZXYsIGl0IGlzIGFzc3VtZWQgYWxsIE1JUCBhcmUgYXV0byBjcmVhdGVkIG9uIGFwcGxpY2FibGUg aW50ZXJmYWNlcy4gSW4gdGhlIG5leHQgcmV2LCBhdCB0aGUgTUEgbGV2ZWwgd2lsbCBpbmNsdWRl IG5vZGUgbWEtYXV0b2NyZWF0ZS4gV2hlbiBkaXNhYmxlLCB3aWxsIGFkZCBhYmlsaXR5IHRvIGNy ZWF0ZSBNSVAgbWFudWFsbHkuIFRoZXJlIHdpbGwgYmUgbm8gc3BlY2lmaWMgTUlQIGFkZHJlc3Mg bGlrZSBpbiBNRVAsIGJ1dCBqdXN0IHRoZSBkaXJlY3Rpb24gYW5kIGF0dGFjaGVkIGludGVyZmFj ZS4NCg0KMi4gVGhlIHJhbmdlIG9mIE1FUCBJRCBpcyBmcm9tIDEgdG8gODE5MS4gSW4gVFJJTEwg T0FNIGZyYW1ld29yaywgdHJpbGwgYmFzZSBtb2RlIGlzIGRlZmluZWQgdG8gZ2VuZXJhdGUgTUQs IE1BLCBhbmQgTUVQIGF1dG9tYXRpY2FsbHksIE1FUCBJRCBjYW4gdXNlIFJCJ3Mgbmlja25hbWUg YW5kIHdpbGwgYmUgYmV5b25kIDgxOTEsIGhvdyBjYW4gaXQgYmUgbWFuYWdlZCB0aHJvdWdoIFlh bmcgbW9kZWw/DQoNClthbnN3ZXJdIG9uIGEgZGlmZmVyZW50IHRocmVhZCBZaSB6aG91IGFsc28g YXNrZWQgbWUgdGhlIHNhbWUgcXVlc3Rpb24uIDgxOTEgdGFrZW4gZnJvbSB0aGUgQ0ZNIE1JQi4g QWx0aG91Z2ggYWN0dWFsIE1FUC1JRCBvbiB0aGUgd2lyZSBpcyAyIGJ5dGVzLCAoU2VjdGlvbiAy MS42IDgwMi4xYWcsIFRhYmxlIDIxLTE1KSBJIHdpbGwgY2hhbmdlIHRoZSByYW5nZSB0byBmdWxs IHJhbmdlIHdoZW4gdGVjaG5vbG9neSBpcyBub3QgQ0ZNLg0KDQozLiBJbiB0cmlsbCBiYXNlIG1v ZGUsIHRoZSBkZWZhdWx0IG5hbWUgZm9yIE1EIGlzICJUcmlsbEJhc2VNb2RlIiwgdGhlIGRlZmF1 bHQgbmFtZSBmb3IgTUEgaXMgIkZGRkMiLiBJZiB0aGV5IGFyZSBjb25mbGljdGVkIHdpdGggdGhl IGNvbmZpZ3VyYXRpb24gZGF0YSwgaG93IGNhbiB3ZSBzb2x2ZSB0aGlzIGlzc3VlPw0KDQoNCg0K W2Fuc3dlcl0gQSBWZXJ5IGdvb2QgcXVlc3Rpb24sIEkgZGlkIG5vdCBpbmNsdWRlIHRoaXMgaW4g dGhlIGluaXRpYWwgdmVyc2lvbiB0byBrZWVwIGl0IHNpbXBsZSBidXQgeW91IGNhdWdodCBpdCA6 KS4NCg0KSW4gdGhlIG5leHQgcmV2IEkgd2lsbCBpbmNsdWRlIGFzIGZvbGxvd3MNCg0KVGhlcmUg Y2FuIGJlIG9uZSBhbmQgb25seSBvbmUgVHJpbGxCYXNlIG1vZGUgcGVyIE1BLg0KDQpJIHdpbGwg ZWl0aGVyIGludHJvZHVjZSB0cmlsbCBmZWF0dXJlIGFuZCBtYWtlIGlmLWZlYXR1cmUgb3Igd2hl biB0ZWNobm9sb2d5PXRyaWxsLCB0byBjcmVhdGUgQmFzZSBtb2RlIG5vZGUuICBNeSBjdXJyZW50 IHByZWZlcmVuY2UgaXMgdG8gdXNlIGlmLWZlYXR1cmUuDQoNClRoYW5rcw0KDQp3ZWlndW8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogbXBscyBbbXBscy1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIFt0c2VuZXZp ckBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNMTqNNTCMsjVIDEwOjU3DQrK1bz+yMs6IG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCtb3 zOI6IFttcGxzXSBZQU5HIG1vZGVsIGZvciBwcm90b2NvbCBpbmRlcGVuZGVudCBPQU0NCkFsbA0K DQpJbiB0aGUgZHJhZnQgYmVsb3cgd2UgcHJlc2VudCBZQU5HIG1vZGVsIHRvIGFic3RyYWN0IHBy b3RvY29sIGRlcGVuZGVudCBhc3BlY3RzIG9mIE9BTSBhbmQgY3JlYXRlIGEgdW5pZmllZCBPQU0g QVBJIHNldC4gSW4gYSBudXRzaGVsbCwgcGluZyBpcyBwaW5nIGFuZCB0cmFjZXJvdXRlIGlzIHRy YWNlcm91dGUgYW5kIHNvIG9uLiBQcm90b2NvbCBpbmRlcGVuZGVudCBBUEkgoa5zIGFsbG93IHVz ZXJzIHRvIGV4ZXJjaXNlIHRoZXNlIE9BTSB0b29scyBpbiB0aGUgc2FtZSBtYW5uZXIgYWNyb3Nz IGRpZmZlcmVudCB0ZWNobm9sb2dpZXMgYW5kIGFsbG93IHRvIGludGVncmF0ZSB0byB0aGVpciBv cGVyYXRpb25zIHBsYXRmb3Jtcy4NCg0KQXBwcmVjaWF0ZSB5b3VyIHRpbWUgb24gcmV2aWV3aW5n IGFuZCBwcm92aWRpbmcgY29tbWVudHMsIGJvdGggb24gQVBJoa9zIGFuZCBZQU5HIG1vZGVsIGFz IHdlbGwgYXMgT0FNIGZyYW1ld29yayBpbiBpdCBzZWxmLg0KDQpodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0tMDAudHh0DQoNClRoYW5rcw0KVGlzc2ENCg== --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Hi Weiguo

     

    Thanks for some very g= ood set of questions, please see the answers below in-line with [answer]

     

    From: Haoweigu= o [mailto:haoweiguo@huawei.com]
    Sent: Tuesday, April 01, 2014 8:51 PM
    To: Tissa Senevirathne (tsenevir); mpls@ietf.org; l2vpn@ietf.org; ne= tmod@ietf.org
    Subject:
    =B4=F0=B8=B4: YANG model for protocol ind= ependent OAM

     

    Hi Tissa,

    Thanks for your presenting the detail Yang = model of TRILL OAM. After read the draft, i have some comments an= d problems as follows.

     

    1. There is no MIP data model in this draft, in = TRILL OAM Framework MIP is definitely defined to filter OAM packet based on= MIP level.

    [answer] I intentionally skipped this for the = initial rev, it is assumed all MIP are auto created on applicable interface= s. In the next rev, at the MA level will include node ma-autocreate. When disable, will add ability to create MIP manually. Ther= e will be no specific MIP address like in MEP, but just the direction and a= ttached interface.


    2. The range of MEP ID is from 1 to 8191. In TRILL OAM framework, trill bas= e mode is defined to generate MD, MA, and MEP automatically, MEP ID can use= RB's nickname and will be beyond 8191, how can it be managed through Yang = model?

    [answer] on a different thread Yi zhou also as= ked me the same question. 8191 taken from the CFM MIB. Although actual MEP-= ID on the wire is 2 bytes, (Section 21.6 802.1ag, Table 21-15) I will change the range to full range when technology is not CFM.


    3. In trill base mode, the default name for MD is "TrillBaseMode"= , the default name for MA is "FFFC". If they are conflicted with = the configuration data, how can we solve this issue?

     

    [answer] A Very good question, I did not incl= ude this in the initial version to keep it simple but you caught it J.

    In the next rev I will include as follows

    There can be one and only one TrillBase mode = per MA.

    I will either introduce trill feature and mak= e if-feature or when technology=3Dtrill, to create Base mode node.  My= current preference is to use if-feature.


    Thanks

    weiguo


    =B7=A2=BC=FE= =C8=CB: mpls [mpls-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
    =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C22=C8=D5 10:57
    =CA=D5=BC=FE=C8=CB: mpls@ietf.org; l2vpn@ietf.org; netmod@ietf.org<= br> =D6=F7=CC=E2: [mpls] YANG model for protocol independent OAM

    All

     =

    In the draft below we pr= esent YANG model to abstract protocol dependent aspects of OAM and create a= unified OAM API set. In a nutshell, ping is ping and traceroute is tracero= ute and so on. Protocol independent API =A1=AEs allow users to exercise these OAM tools in the same manner acr= oss different technologies and allow to integrate to their operations platf= orms.

     =

    Appreciate your time on = reviewing and providing comments, both on API=A1=AFs and YANG model as well= as OAM framework in it self.

     =

    http://www.ietf.= org/id/draft-tissa-netmod-oam-00.txt

     =

    Thanks=

    Tissa<= /p>

    --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_-- From nobody Tue Apr 1 22:31:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957741A00EA; Tue, 1 Apr 2014 20:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqQPveb-UFwr; Tue, 1 Apr 2014 20:51:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE6E11A00E1; Tue, 1 Apr 2014 20:51:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCQ67856; Wed, 02 Apr 2014 03:51:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:50:14 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:51:07 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 2 Apr 2014 11:51:05 +0800 From: Haoweiguo To: "Tissa Senevirathne (tsenevir)" , "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVwwABSb29 Date: Wed, 2 Apr 2014 03:51:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.22.248] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7f-YXmAkIqq20Nr7Z9OC3XlLHWU X-Mailman-Approved-At: Tue, 01 Apr 2014 22:31:26 -0700 Subject: [netmod] =?gb2312?b?tPC4tDogWUFORyBtb2RlbCBmb3IgcHJvdG9jb2wgaW5k?= =?gb2312?b?ZXBlbmRlbnQgT0FN?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 03:51:15 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGlzc2EsDQoNClRoYW5rcyBmb3IgeW91ciBwcmVzZW50aW5nIHRoZSBkZXRhaWwgWWFuZyBt b2RlbCBvZiBUUklMTCBPQU0uIEFmdGVyIHJlYWQgdGhlIGRyYWZ0LCBpIGhhdmUgc29tZSBjb21t ZW50cyBhbmQgcHJvYmxlbXMgYXMgZm9sbG93cy4NCg0KDQoNCjEuIFRoZXJlIGlzIG5vIE1JUCBk YXRhIG1vZGVsIGluIHRoaXMgZHJhZnQsIGluIFRSSUxMIE9BTSBGcmFtZXdvcmsgTUlQIGlzIGRl ZmluaXRlbHkgZGVmaW5lZCB0byBmaWx0ZXIgT0FNIHBhY2tldCBiYXNlZCBvbiBNSVAgbGV2ZWwu DQoNCjIuIFRoZSByYW5nZSBvZiBNRVAgSUQgaXMgZnJvbSAxIHRvIDgxOTEuIEluIFRSSUxMIE9B TSBmcmFtZXdvcmssIHRyaWxsIGJhc2UgbW9kZSBpcyBkZWZpbmVkIHRvIGdlbmVyYXRlIE1ELCBN QSwgYW5kIE1FUCBhdXRvbWF0aWNhbGx5LCBNRVAgSUQgY2FuIHVzZSBSQidzIG5pY2tuYW1lIGFu ZCB3aWxsIGJlIGJleW9uZCA4MTkxLCBob3cgY2FuIGl0IGJlIG1hbmFnZWQgdGhyb3VnaCBZYW5n IG1vZGVsPw0KDQozLiBJbiB0cmlsbCBiYXNlIG1vZGUsIHRoZSBkZWZhdWx0IG5hbWUgZm9yIE1E IGlzICJUcmlsbEJhc2VNb2RlIiwgdGhlIGRlZmF1bHQgbmFtZSBmb3IgTUEgaXMgIkZGRkMiLiBJ ZiB0aGV5IGFyZSBjb25mbGljdGVkIHdpdGggdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSwgaG93IGNh biB3ZSBzb2x2ZSB0aGlzIGlzc3VlPw0KDQpUaGFua3MNCg0Kd2VpZ3VvDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IG1wbHMgW21wbHMtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSBbdHNlbmV2aXJAY2lzY28uY29t XQ0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjLI1SAxMDo1Nw0KytW8/sjLOiBtcGxzQGlldGYub3JnOyBs MnZwbkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQrW98ziOiBbbXBsc10gWUFORyBtb2RlbCBm b3IgcHJvdG9jb2wgaW5kZXBlbmRlbnQgT0FNDQoNCkFsbA0KDQpJbiB0aGUgZHJhZnQgYmVsb3cg d2UgcHJlc2VudCBZQU5HIG1vZGVsIHRvIGFic3RyYWN0IHByb3RvY29sIGRlcGVuZGVudCBhc3Bl Y3RzIG9mIE9BTSBhbmQgY3JlYXRlIGEgdW5pZmllZCBPQU0gQVBJIHNldC4gSW4gYSBudXRzaGVs bCwgcGluZyBpcyBwaW5nIGFuZCB0cmFjZXJvdXRlIGlzIHRyYWNlcm91dGUgYW5kIHNvIG9uLiBQ cm90b2NvbCBpbmRlcGVuZGVudCBBUEkgoa5zIGFsbG93IHVzZXJzIHRvIGV4ZXJjaXNlIHRoZXNl IE9BTSB0b29scyBpbiB0aGUgc2FtZSBtYW5uZXIgYWNyb3NzIGRpZmZlcmVudCB0ZWNobm9sb2dp ZXMgYW5kIGFsbG93IHRvIGludGVncmF0ZSB0byB0aGVpciBvcGVyYXRpb25zIHBsYXRmb3Jtcy4N Cg0KQXBwcmVjaWF0ZSB5b3VyIHRpbWUgb24gcmV2aWV3aW5nIGFuZCBwcm92aWRpbmcgY29tbWVu dHMsIGJvdGggb24gQVBJoa9zIGFuZCBZQU5HIG1vZGVsIGFzIHdlbGwgYXMgT0FNIGZyYW1ld29y ayBpbiBpdCBzZWxmLg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRpc3NhLW5ldG1v ZC1vYW0tMDAudHh0DQoNClRoYW5rcw0KVGlzc2ENCg== --_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Hi Tissa,

    Thanks for your presenting the detail Yang model of TRILL OAM. Afte= r read the draft, i have some comments and problems as follows.

     

    1. There is no MIP data model in this draft, in TRILL OAM Framework MIP = is definitely defined to filter OAM packet based on MIP level.


    2. The range of MEP ID is from 1 to 8191. In TRILL OAM framework, trill bas= e mode is defined to generate MD, MA, and MEP automatically, MEP ID can use= RB's nickname and will be beyond 8191, how can it be managed through Yang = model?


    3. In trill base mode, the default name for MD is "TrillBaseMode"= , the default name for MA is "FFFC". If they are conflicted with = the configuration data, how can we solve this issue?


    Thanks

    weiguo

    =B7=A2=BC=FE=C8=CB: mpls [mpls-bounces@iet= f.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
    =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C22=C8=D5 10:57
    =CA=D5=BC=FE=C8=CB: mpls@ietf.org; l2vpn@ietf.org; netmod@ietf.org =D6=F7=CC=E2: [mpls] YANG model for protocol independent OAM

    All

     

    In the draft below we present YANG model to abstract= protocol dependent aspects of OAM and create a unified OAM API set. In a n= utshell, ping is ping and traceroute is traceroute and so on. Protocol inde= pendent API =A1=AEs allow users to exercise these OAM tools in the same manner across different technologies and allow= to integrate to their operations platforms.

     

    Appreciate your time on reviewing and providing comm= ents, both on API=A1=AFs and YANG model as well as OAM framework in it self= .

     

    http://www.ietf.org/id/draft-tissa-netmod-oa= m-00.txt

     

    Thanks

    Tissa

    --_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_-- From nobody Wed Apr 2 01:17:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331B01A016D for ; Wed, 2 Apr 2014 01:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2WMU4qK4xKS for ; Wed, 2 Apr 2014 01:16:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE511A0168 for ; Wed, 2 Apr 2014 01:16:56 -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 0050B394158; Wed, 2 Apr 2014 10:16:51 +0200 (CEST) Date: Wed, 02 Apr 2014 10:16:51 +0200 (CEST) Message-Id: <20140402.101651.1949871552351850844.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-mFQsZQgwhrc-AkPjkXLwKbtkrs Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: remove deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 08:17:02 -0000 Andy Bierman wrote: > Hi, > > I don't think YANG deviation statements are being used, Deviations are used. One data point: I recently extended the support for deviations in pyang, based on requests from open source users. /martin > nor are they likely to ever be used. They are not allowed > to appear in standard YANG modules, so I am asking > vendors out there: > > Do you use (or plan to use) deviation statements in your YANG modules? > > If consensus is no, then deviations should be removed from YANG 1.1. > YANG would be simpler without them. > IMO, conformance information should be handled differently anyway. From nobody Wed Apr 2 09:21:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9F1A035C for ; Wed, 2 Apr 2014 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRD2raq3Jqtu for ; Wed, 2 Apr 2014 09:21:23 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8716F1A0254 for ; Wed, 2 Apr 2014 09:21:23 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so470794qcx.10 for ; Wed, 02 Apr 2014 09:21:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oes8SOmKai7YMeXfALG6lplNoIBlr5NGPlMdJChXwuc=; b=bGJO/jou8blnLjzZ4sxd7ppWhwXUm+LIKs8g9q6H7/YXYl7NIYktZuKEG1ilhDQ377 eiV8Y0hBAKFdFwKqsLfLweBe/LEE0Q5ietQJVdeKSIXtpfBW6j2x2TYahovalm0fAHtj gfAdifBHJC8q3NnVQNsTUO9EtW8+XcoIDjKYhuSIMHHGFkAyil2TTj8FZG5FDeGxsLpY t+0dvi9LPqmVGwKmL+sqqNwJXPsVx3U2hB8nB+bJVXfVhslnyN6JE1EUv+4cFrGHlxxC 3PYIp+ycbkcFpjCMOckt1B76YhbDInGdexsIs48pYsVmh7a39DzA8HuuJuN3/1d+0If8 CeCQ== X-Gm-Message-State: ALoCoQkG05E8VoKSc9ebDo2VIgN3lh5skvmSg46Cv6ruPEpiff5Zq7StKM77UaZJhwY5k5rL/SDv MIME-Version: 1.0 X-Received: by 10.224.125.194 with SMTP id z2mr1530612qar.99.1396455679296; Wed, 02 Apr 2014 09:21:19 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 2 Apr 2014 09:21:19 -0700 (PDT) In-Reply-To: <20140402.101651.1949871552351850844.mbj@tail-f.com> References: <20140402.101651.1949871552351850844.mbj@tail-f.com> Date: Wed, 2 Apr 2014 09:21:19 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c20688b5b77404f611ac3f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DMnuoixqu_flM74vN6aIGPc108E Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 issue: remove deviations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:21:29 -0000 --001a11c20688b5b77404f611ac3f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 2, 2014 at 1:16 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I don't think YANG deviation statements are being used, > > Deviations are used. One data point: I recently extended the support > for deviations in pyang, based on requests from open source users. > > > OK -- I was just checking. In theory they are very useful if the server does not instrument objects correctly, then the client can identity the trouble spots automatically. This is better than each platform group publishing its own version of the foo module. /martin > Andy > > > nor are they likely to ever be used. They are not allowed > > to appear in standard YANG modules, so I am asking > > vendors out there: > > > > Do you use (or plan to use) deviation statements in your YANG modules? > > > > If consensus is no, then deviations should be removed from YANG 1.1. > > YANG would be simpler without them. > > IMO, conformance information should be handled differently anyway. > > --001a11c20688b5b77404f611ac3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 2, 2014 at 1:16 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
    Andy Bierman <andy@yumaworks.com> wrote:
    > Hi,
    >
    > I don't think YANG deviation statements are being used,

    Deviations are used. =A0One data point: I recently extended the support
    for deviations in pyang, based on requests from open source users.



    OK -- I was just checking.
    I= n theory they are very useful if the server does not instrument objects
    correctly, then the client can identity the trouble spots automatica= lly.
    This is better than each platform group publishing its own version
    of the foo module.


    /martin

    Andy

    = =A0

    > nor are they likely to ever be used. They are not allowed
    > to appear in standard YANG modules, so I am asking
    > vendors out there:
    >
    > =A0 =A0Do you use (or plan to use) deviation statements in your YANG m= odules?
    >
    > If consensus is no, then deviations should be removed from YANG 1.1. > YANG would be simpler without them.
    > IMO, conformance information should be handled differently anyway.


    --001a11c20688b5b77404f611ac3f-- From nobody Wed Apr 2 21:30:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8901A000A for ; Wed, 2 Apr 2014 21:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofCk44gZ48J3 for ; Wed, 2 Apr 2014 21:30:04 -0700 (PDT) Received: from nm31.bullet.mail.ne1.yahoo.com (nm31.bullet.mail.ne1.yahoo.com [98.138.229.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB661A0024 for ; Wed, 2 Apr 2014 21:30:03 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 03 Apr 2014 04:29:59 -0000 Received: from [98.138.100.112] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 03 Apr 2014 04:27:12 -0000 Received: from [66.196.81.171] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 03 Apr 2014 04:27:06 -0000 Received: from [98.139.212.195] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 04:27:06 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 04:27:06 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 855370.32948.bm@omp1004.mail.bf1.yahoo.com Received: (qmail 31675 invoked by uid 60001); 3 Apr 2014 04:27:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1396499226; bh=7Kfawq19Rw7Y5zDaEMVw3txDwNnKD1Qro/evrHIRFXQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FCAC27Ul7nKtgueb2Pw4+TU/F8W0+WbYHyQJDFjUwL5JmO1UjsJwiCngjKZSt+5BV/2lCE2AiSuMJVziK6JOnaqSDNfNtSOfewF5lSQNeyPWDehouat1ppaB5uXsgYskykqrUctsIfu9nZ1V4ErDN7Ft0iajV7Dtm4MGFQNVZ5U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WhcopoivRK2zzwatCewaWiUIR0bvQWcMlYIP5jmEKgm3K8evgKvwwfCDedcSwuVp5tePFc+8ghGcTh/lMdG4d3f2DLxk5HHH3UQ80iHWrggHo/x+3mnMdcZrCE7/NGrh3Kg+0JbeFfv5RS9UFD3+vqgof2N7hjT7PwdUiNpsMII=; X-YMail-OSG: qbSzB0IVM1myGTbqRPJ.IJlIo.GYWo2XgQ3RLkY_mFX9Uaz oqOMP2BUjDRA2_avL2sROe27F9DdPfcYRgfEbiebsIC.iJVUmKxfFWy_bVMU XKGT_kZgD4k8Hone_kBQqAu9wLBB5oAhCKmpUc2L6JV6oz7clG6xCK863V7t xnQ0d0HIA2i3jibconQ8S3xvdXGpOOW9pscbN1pcvf9FyVDl0TxnyKKhSQPE GtuyVcDnNeSSW0q3Oba0293V0EME5dnWoEmAkDIAaXKMFedcq759pSOywvJW vmpYW_T9Ucxj3NwWypZgpTv4Cf6pxpL56.RyrkBoHB1kb6.0l6C2sbGEbZEH RhQyleH4vYmL4zjVfBwawH5zTrCVGzbPlKeigt9u4RTkhWG16igJ5i5P82mY VLg2qvIAQY4XB557ujz7SbCNijTegrkUw9GhUD0ihTGKKJUQg7M9tPKVBEn0 I9ZyECUjreXwltl2cl3N6212ZpfiwCV.j8m9feb32g2eWi3E9SVydnSg0PmV jc4rAadADxUrDLJ2oDMt.Rl_mvhogw_DZQHJzEy15bYRHRoK2xMfvp1jjouA 6J60- Received: from [67.180.85.155] by web162501.mail.bf1.yahoo.com via HTTP; Wed, 02 Apr 2014 21:27:06 PDT X-Rocket-MIMEInfo: 002.001, SGkgTGlzYSwKClRoYW5rcyBmb3IgeW91ciByZXBseS7CoAoKUGxlYXNlIHNlZSBpbmxpbmUgd2l0aCBbU3RldmVdLgoKdGhhbmtzLAoKU3RldmUKT24gVHVlc2RheSwgQXByaWwgMSwgMjAxNCA0OjUyIFBNLCBMaXNhIEh1YW5nICh5aWh1YW4pIDx5aWh1YW5AY2lzY28uY29tPiB3cm90ZToKIApTdGV2ZSzCoENvbW1lbnRzIGluIGxpbmUuIC0tTGlzYQoKRnJvbTogc3RldmUgY2hlbmcgPHNjaGVuZzk4Xzk4QHlhaG9vLmNvbT4KUmVwbHktVG86IHN0ZXZlIGNoZW5nIDxzY2hlbmc5OF85OEB5YWhvby5jb20.CkQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <1396116711.53102.YahooMailNeo@web162504.mail.bf1.yahoo.com> Message-ID: <1396499226.70452.YahooMailNeo@web162501.mail.bf1.yahoo.com> Date: Wed, 2 Apr 2014 21:27:06 -0700 (PDT) From: steve cheng To: "Lisa Huang \(yihuan\)" , "netmod@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1748018769-1271795659-1396499226=:70452" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hU6oM_LZkHUZSm7wEZqbE9CGwN0 Subject: Re: [netmod] Suggestions for draft-huang-netmod-acl-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: steve cheng List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 04:30:08 -0000 --1748018769-1271795659-1396499226=:70452 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lisa,=0A=0AThanks for your reply.=C2=A0=0A=0APlease see inline with [Ste= ve].=0A=0Athanks,=0A=0ASteve=0AOn Tuesday, April 1, 2014 4:52 PM, Lisa Huan= g (yihuan) wrote:=0A =0ASteve,=C2=A0Comments in line. --= Lisa=0A=0AFrom: steve cheng =0AReply-To: steve cheng= =0ADate: Saturday, March 29, 2014 11:11 AM=0ATo: "n= etmod@ietf.org" =0ASubject: [netmod] Suggestions for draft= -huang-netmod-acl-03.txt=0A=0A=0AHi Lisa/Alex/Andy,=0A=0AI saw current draf= t doesn't cover how SPF (ACL) is applied on an interface or other client ap= plications. =0A=0A Section 3.3.4 of the draft=C2=A0briefly covers how= to apply SPF(ACL) =C2=A0to interface =C2=A0and also=C2=A0gives an example = of how to attach an SPF to an interface.=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AWe typically call the= se SPF(ACL) on an interface for packet filtering as Security ACL. For examp= le, =0Ainterface foo=0A=C2=A0=C2=A0=C2=A0 SPF(ACL) bar ingress/egress=0A=0A= Would it make sense to create a new draft? =0A Yes. You could create = a new module which augment interface module and add SPF(ACL) leaf list. Sec= tion 3.3.4 has an example of that.=C2=A0=0A=0A[Steve] OK=0A=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AAnother k= ind of widely deployed SPF(ACL) is in other client applications. QoS, PBR, = and routing protocols such as OSPF/BGP are some examples. =0A=0A=09* For Qo= S/PBR/other policy based applications, it's used for classification. For ex= ample QoS, =0A=0A=09* class foo: match SPF (ACL), =0A=0A=09* policy bar: ma= tch class foo, rate limiting=0A=09* policy bar is applied on an interface i= ngress/egress=0AOne way is:=0AImport stateless-pf {=0Aprefix "spf";= =0A}=0A=E2=80=A6=0AList class {=0AKey "name";=0ALeaf "name" {=0A=E2=80=A6= =0A}=0ALeaf-list match {=0Atype "spf:spf-ref";=0A}=0A}=0A=0A=0A[Steve] we c= an discuss more about this if QoS/PBR YANG modeling is in the picture in th= e future.=0A=09* For routing protocols, it's used for route/prefix filterin= g (not packet filtering).=0A prefix filter is different from access l= ist since it has less filtering options and don't distinguish packet source= and destination. Since both filter has similarity, prefix filtering can re= use most of the grouping definition in SPF(ACL).=0A[Steve] Agree, prefix li= st is different from access list. Well many existing routing applications d= o use ACL (not prefix-list) widely.=C2=A0=0A=0A=0A=09* some other applicati= ons can simply use ACL (SPF) to filter out debugging output.=0AIs thi= s the use case described in CLI?=0Aaccess-list 101 permit tcp any host 192.= 168.35.1 range 20 21 access-list 102 permit tcp host 192.168.35.1 any estab= lished interface ethernet 0 access-group 101 out access-group 102 in=0AIn t= his case, the configuration is a single unnamed ACE in ACL but ACE name is = a mandatory leaf=C2=A0in=C2=A0the draft. The implementation is not in scope= of the draft, but one way to implement is to add an adapter of netconf eng= ine and backend. The job of the adapter is to map name based ACE(netconf co= nfig) to single no name ACE(system) back and forth. =0AList access-group {= =0AKey "spf-name";=0ALeaf "spf-name" {type "spf:spf-ref";=0A}=0ALeaf =C2=A0= dirction {=0Atype enumeration {=0AEnum "in";=0AEnum "out";=0A}=0A}=0A}=0A[S= teve] No, this is not the case. Logically it could be as simple as this,=C2= =A0=0Adebugging feature filter =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D= =3D=3D=3D> only debugging msg with ACL defined src/dest ip/port will be dis= played.=0A=0A=0A=0AAny suggestion on how to deal with them? =0A=0A=0A=0A=0A= cheers,=0A=0ASteve Cheng --1748018769-1271795659-1396499226=:70452 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi Lisa,

    Thanks for your reply. 

    Please see inline with [Steve].
    =

    thanks,

    Steve
    On Tuesday, April 1, 2014 4:52 P= M, Lisa Huang (yihuan) <yihuan@cisco.com> wrote:
    =
    =0A
    Steve= , Comments in line. --Lisa
    =0A

    =0A
    = =0A=0A
    =0AFrom: steve cheng <scheng98_98@yahoo.com>
    =0AReply-To: steve cheng <scheng98_98@yahoo.com>=0ADate: Saturday,= March 29, 2014 11:11 AM
    =0ATo: "netmod@ietf.o= rg" <netmod@ietf.org>
    =0ASubject: [netmod] Suggestions for draft-huang-netmod-acl-03.txt
    = =0A
    =0A

    =0A
    =0A
    =0A
    =0A
    =0AHi Lisa/Alex/Andy,
    =0A
    =0AI saw current draft doesn't cover how SPF (ACL) is applied on= an interface or other client applications.=0A
    =0A
    =0A
    =0A= =0A

    =0A
    =0A
    <Lisa> Section 3.3.4 of t= he draft briefly covers how to apply SPF(ACL)  to interface  = ;and also gives an example of how to attach an SPF to an interface.=0A=0A
    =0A=0A
    =0A
    =0A=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    =0A
    =0AWe typically call these SPF(ACL) on an inte= rface for packet filtering as Security ACL. For example,=0A
    =0Ainterface foo
    =0A    SPF(ACL) bar in= gress/egress
    =0A
    =0AWould it make sense= to create a new draft?
    =0A
    =0A
    =0A=0A
    <Lisa> Yes= . You could create a new module which augment interface module and add SPF(= ACL) leaf list. Section 3.3.4 has an example of that. 
    =0A=0A
    =0A
    =0A
    =0A
    =0A[Steve] OK
    =0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
    =0A
    =0AAnother kind of widely= deployed SPF(ACL) is in other client applications. QoS, PBR, and routing p= rotocols such as OSPF/BGP are some examples.=0A
    =0A
    • For QoS/PBR/other policy based applications, it's used for cl= assification. For example QoS,=0A
      =0A
      • class foo: m= atch SPF (ACL),
        =0A
      • policy bar: match class foo,= rate limiting
      • policy bar is applied on an interface ingress/egress=
      =0A
    =0A
    =0A
    =0A
    =0A=0A
    <Lisa>On= e way is:
    =0A
    Import stateless-pf {
    =0A
    prefix "spf";<= /div>=0A
    }
    =0A
    =E2=80=A6
    =0A
    List class {
    =0AKey "name";
    =0A
    Leaf "name" {
    =0A
    =E2=80=A6=0A
    }
    =0A
    Leaf-list match {
    =0A
    type "sp= f:spf-ref";
    =0A
    }
    =0A
    }
    =0A=0A
    =0A
    =0A
    =0A
    =0A

    =0A
    [Steve] we can = discuss more about this if QoS/PBR YANG modeling is in the picture in the f= uture.
    =0A
    =0A
    • For routing protocols, it's use= d for route/prefix filtering (not packet filtering).
    =0A
    =0A<= /div>=0A
    =0A=0A
    <Lisa> prefix filter is different from acces= s list since it has less filtering options and don't distinguish packet sou= rce and destination. Since both filter has similarity, prefix filtering can= reuse most of the grouping definition in SPF(ACL).
    [Steve] Agree= , prefix list is different from access list. Well many existing routing app= lications do use ACL (not prefix-list) widely. 
    =0A=0A
    =0A
    =0A
    =0A

    =0A
    =0A
      some other applications can simply use ACL (SPF) to filter out debugging = output.
    =0A
    =0A<Lisa>Is this the use case described in CLI?
    =0A
    =0A=
    =0A
    =0A=0A
    =0A
    access-list 101=
     permit tcp any host 192.168.35.1 range 20 21=0Aaccess-list 102 permit tcp host 192.168.35.1 any established<=
    /code>=0Ainterface ethernet 0=0Aaccess-group 101 out=0Aaccess-group 102 in
    =0A
    In this case, the co=
    nfiguration is a single unnamed ACE in ACL but ACE name is a mandatory leaf=
     in the draft. The implementation is not in scope of the draft, b=
    ut one way to implement is to add an adapter of netconf engine and backend.=
     The job of the adapter is to map name based ACE(netconf config) to single =
    no name ACE(system) back and forth. 
    =0A
    List access-group {
    =09Key "spf-name";<= /div>
    =09Leaf "spf-name" {
    =09=09type "spf:spf-ref";
    =09=09
    =09}
    <= div style=3D"background-color:rgb(255, 255, 255);">=09Leaf  dirctio= n {
    =09=09type = enumeration {
    =09=09= =09Enum "in";
    =09=09=09Enum "out";
    =09=09}
    =09}
    }<= /div>
    [Steve] No, this i= s not the case. Logically it could be as simple as this, 
    debugging feature filter <A= CL>           =3D=3D=3D=3D> only debugging m= sg with ACL defined src/dest ip/port will be displayed.



    =0A
    =0A=0A
    =0A
    =0A
    =0A=0AAny sugge= stion on how to deal with them?
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A
    =0A
    =0A
    =0A=
    =0A=
    =0A
    =0A
    =0A
    =0A
    =0Acheers,
    =0A
    =0A
    =0A
    =0A
    =0A<= span>Steve Cheng
    =0A
    =0A
    =0A
    =0A

    =0A
    =0A
    =0A
    =0A
    =0A=0A

    --1748018769-1271795659-1396499226=:70452-- From nobody Thu Apr 3 02:23:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCAF1A010E for ; Thu, 3 Apr 2014 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEYd1sgBdz5H for ; Thu, 3 Apr 2014 02:23:00 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 917091A00DB for ; Thu, 3 Apr 2014 02:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3981; q=dns/txt; s=iport; t=1396516976; x=1397726576; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=JkiGFwmedJlSefz3JphUPPi/rFQd1owXBN4WPWAOexk=; b=R221Q4/yAS+ik1zxFNdGnEj1o0dz4TLU9Q1ictp4sgM6NSlGYiUKTwcX BwbYfcC+hrgfScVcwYrFqu9KYt39AOeqccMw54yZtdJz76O3UmhgNHJdu KOv0TkPzLADIiuSfPpm0l+uyRVKxvfG6vZpfyPzBLeoQjXdbB86waV7AO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFAAIbPVOtJssH/2dsb2JhbABYgwY7iT2zV4ZkUYEdFnSCJQEBAQQBAQFrCgEQCwQUCRYPCQMCAQIBFTATAQUCAQGHdQ3PaxMEjh1UBxaEIgSYWYZRi22DMjs X-IronPort-AV: E=Sophos; i="4.97,785,1389744000"; d="scan'208,217"; a="12979130" Received: from aer-core-2.cisco.com ([173.38.203.7]) by aer-iport-2.cisco.com with ESMTP; 03 Apr 2014 09:22:55 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s339MYut011539; Thu, 3 Apr 2014 09:22:34 GMT Message-ID: <533D285A.1000701@cisco.com> Date: Thu, 03 Apr 2014 11:22:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20140304134348.GA27138@elstar.local> <20140305172730.GA31399@elstar.local> In-Reply-To: <20140305172730.GA31399@elstar.local> Content-Type: multipart/alternative; boundary="------------000708050608040909050900" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_OfgxLNgc91mAlClyQkJLo9MM8g Cc: Joel jaeggli Subject: Re: [netmod] netmod charter revision (version 2014-03-04) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 09:23:05 -0000 This is a multi-part message in MIME format. --------------000708050608040909050900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Jrgen, This new charter proposal, updated at , is on the IESG telechat next Thursday, for "Internal Review". Regards, Benoit > On Tue, Mar 04, 2014 at 02:43:48PM +0100, Juergen Schoenwaelder wrote: >> Hi, >> >> here is another charter text proposal based on the feedback received >> on the mailing list and during hallway discussions at the IETF in >> London. Please read and comment. We plan to resolve the charter >> revision discussion tomorrow at the WG meeting. But please, if you >> have issues with the new proposal, please raise them as soon as >> possible (it is good to be aware of any issues before the meeting). >> > I have udpated the charter text based on the feedback received so > far. In particular, I have > > - applied the fix posted previously to address Lada's comment > - fixed the wording in the milestones list > - added a pointer to YANG doctors so people know where to go > - checked the usage of NETCONF (and as part of that changed > 'planned work in NETCONF' to 'work in NETCONF') > - changed 'new data modeling concepts' to 'fundamentally new data > modeling concepts' in the hope that this makes the intention a > bit clearer > > Benoit, you may want to upload this to the tracker so people can > easily see the diff. > > /js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------000708050608040909050900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Hi Jürgen,

    This new charter proposal, updated at , is on the IESG telechat next Thursday, for "Internal Review".

    Regards, Benoit
    On Tue, Mar 04, 2014 at 02:43:48PM +0100, Juergen Schoenwaelder wrote:
    
    Hi,
    
    here is another charter text proposal based on the feedback received
    on the mailing list and during hallway discussions at the IETF in
    London. Please read and comment. We plan to resolve the charter
    revision discussion tomorrow at the WG meeting. But please, if you
    have issues with the new proposal, please raise them as soon as
    possible (it is good to be aware of any issues before the meeting).
    
    
    I have udpated the charter text based on the feedback received so
    far. In particular, I have
    
    - applied the fix posted previously to address Lada's comment
    - fixed the wording in the milestones list
    - added a pointer to YANG doctors so people know where to go
    - checked the usage of NETCONF (and as part of that changed
      'planned work in NETCONF' to 'work in NETCONF')
    - changed 'new data modeling concepts' to 'fundamentally new data
      modeling concepts' in the hope that this makes the intention a
      bit clearer
    
    Benoit, you may want to upload this to the tracker so people can
    easily see the diff.
    
    /js
    
    


    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod
    

    --------------000708050608040909050900-- From nobody Thu Apr 3 08:54:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5651C1A0273 for ; Thu, 3 Apr 2014 08:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TmUk4owHHBA for ; Thu, 3 Apr 2014 08:53:51 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 231D41A0299 for ; Thu, 3 Apr 2014 08:53:51 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so1267405qgf.7 for ; Thu, 03 Apr 2014 08:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bOxHyycrAQ0tZRnXAVhyh3MdrEZrk8cnsU692CtvZj0=; b=DvPhBOK/EdnwgqF9GvT0cHVm4RkGVwD/uah68BJcuUa//H/4zNhqhtNpouBiWuVUEo QNCqiofD6iQ9WrWUezcT+wRka30uurWZn0+XJCdKtMdD2lOG5UoHvChtXFNEK4Svl5ix pszdjBJSsX2iYhXJmNFOEa4HUFfQD6nmIBHnqoX3LZecnTMQwgNkKR8LRhdHN6F8Qn/H BXuqXcKR6IrN+Ulre3Wmn3qh1Ap0p6rXeZYiFvxsodA5PZBzpwsQB2UHaScHYKBUPmMq 21foLwK9e/dbDgRvHqegEixLmdfEja1YowHGfzOWrm2Z0r3YHsBwUXmRxnxasKh0cctw KYzA== MIME-Version: 1.0 X-Received: by 10.224.50.71 with SMTP id y7mr8500404qaf.36.1396540426413; Thu, 03 Apr 2014 08:53:46 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Thu, 3 Apr 2014 08:53:46 -0700 (PDT) Date: Thu, 3 Apr 2014 23:53:46 +0800 Message-ID: From: chong feng To: netmod@ietf.org Content-Type: multipart/alternative; boundary=047d7bf0e14e07ec1404f62568d7 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Wma0l7kIBVD7twPVOE9qPZs8XdQ Subject: [netmod] new YANG 1.1 issue: add expression of patterns' relation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:53:56 -0000 --047d7bf0e14e07ec1404f62568d7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, It's not possible to express the relation of patterns. For example, leaf a { type string { pattern p1; pattern p2; pattern p3; } } It's not possible to express ( p1 | p3) & p2. So, YANG1.1 can add 3 statements:patterns , regex and relation to express this relation. 'patterns' statement as type(string)'s sub statement, and for compatible, 'pattern' statement will be reserved 'patterns' statement has no argument and has some sub statements listed below: +---------------+--------------+ | substatement | cardinality | +---------------+--------------+ | description | 0..1 | | error-app-tag | 0..1 | | error-message | 0..1 | | reference | 0..1 | | pattern | 0..n | | relation | 0..1 | +---------------+--------------+ 'pattern' statement is a sub statement of 'patterns' and is not the same to the 'pattern' statement as the sub statement of type(string). So, it's called new 'pattern' statement. the new 'pattern' statement has a argument 'name',it's not regular expression,it's just a pattern identifier.The new 'pattern' statement has some sub statements listed below: +---------------+--------------+ | substatement | cardinality | +---------------+--------------+ | description | 0..1 | | error-app-tag | 0..1 | | error-message | 0..1 | | reference | 0..1 | | regex | 1 | +---------------+--------------+ 'regex' statement has an argument 'expression',this argument is a regular expression,and 'regex' statement has no sub statements. 'realation' statement has an argument "expression", this argument is a logical expression,such as (p1 | p2)&p3,etc. And this statement has no sub statement. For example: leaf a { type string { patterns { pattern p1 { regex "[a-z]"; } pattern p2 { regex "[0-9]" } relation "(p1 | p2)"; } pattern "abc"; } } --047d7bf0e14e07ec1404f62568d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi all,
    =A0 =A0 It's not possible = to express the relation of patterns. For example,
    =A0 =A0 =A0leaf= a {
    =A0 =A0 =A0 =A0 =A0 =A0 type string {
    =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0pattern p1;
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pattern p2;
    =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0pattern p3;
    =A0 =A0 =A0 =A0 =A0 =A0 }
    =A0 =A0 =A0}

    It's not possible to expres= s ( p1 | p3) & p2.

    So, YANG1.1 can add 3 state= ments:patterns , regex and relation=A0
    to express this relation.=A0

    'patterns= 9; statement as type(string)'s sub statement, and for compatible,
    =
    'pattern' statement will be reserved


    'patterns' statement has no argument and has some su= b statements listed below:
    +---------------+--------------+
    =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| substatement =A0| cardinality =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---------------+--------------+
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| description =A0 | =A00..1 =A0 = =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| error-app-tag |= =A00..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| er= ror-message | =A00..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| reference =A0 =A0 | =A00..1 =A0 = =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| pattern =A0 =A0= =A0 | =A00..n =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| relation =A0 =A0 =A0| =A00..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0+---------------+--------------+

    'pattern' statement is a sub statement of '= patterns' and is not the same to the 'pattern' statement as the= sub statement of type(string).
    So, it's called new 'patt= ern' statement.
    the new 'pattern' statement has a argument 'name',it&#= 39;s not regular expression,it's just a pattern identifier.The new '= ;pattern' statement=A0
    has some sub statements listed below:<= /div>
    +----------= -----+--------------+
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| substa= tement =A0| cardinality =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+= ---------------+--------------+
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| description =A0 | =A00..1 =A0 =A0 =A0 = =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| error-app-tag | =A00..1= =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| error-mess= age | =A00..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| reference =A0 =A0 | =A00..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| regex =A0 =A0 =A0 =A0 | =A01 =A0 = =A0 =A0 =A0 =A0 |
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-----------= ----+--------------+=A0
    =A0'regex' statement has an argum= ent 'expression',this argument is a regular expression,and 'reg= ex' statement has no sub statements.
    =A0
    =A0'realation' statement has an argument "e= xpression", this argument is a logical expression,such as (p1 | p2)&am= p;p3,etc. And this statement has=A0
    =A0no sub statement.
    =A0
    =A0For example: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0

    =A0 =A0 =A0leaf a {
    =A0 =A0 =A0 =A0 =A0 =A0 type string {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patterns {
    =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 = pattern p1 {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regex "[a-z]";
    =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 }
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pattern p2 {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 regex "[0-9]"
    =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 }
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 relation "(p1 | p2)";
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
    =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0pattern "abc";
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0
    =A0 =A0 =A0 =A0 =A0 =A0 }
    =A0 =A0 =A0}
    --047d7bf0e14e07ec1404f62568d7-- From nobody Thu Apr 3 08:57:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5E61A027B for ; Thu, 3 Apr 2014 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoLUZCroyUFJ for ; Thu, 3 Apr 2014 08:57:06 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 400AE1A0212 for ; Thu, 3 Apr 2014 08:56:58 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so2111586qcx.32 for ; Thu, 03 Apr 2014 08:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OrouM5/lzeSJ2PDQqLJ2ChcszbteeMBXpWHfHR+2GUg=; b=lGeVv3sOrIjfB+lIJKH67bMkSp9KzpzO5lK6sA1CNc1dab0akfzXHfb37y4iUN0/j8 ybN9rRTgDhFk3eeQx1liwnt19q4fzjJVjqTVQ5au7/j3OR2nkaTqvq6aBdWsX5pUazld uiyC9lBdklfz1O+Hzu+pGmncdtlkiITCNlRwPNcaCp3D1/Qs8epFzuJA6+m6gcs6KMpu 14ZrHtq3XUSFctLOzP7ZFy3FdafUGY1pYXQBWWEkAUFDE/c/uBfl3Z+tyMd9El8dyg5w 6QhlgwTPFHQsbgfI12c9VvAhr/XD5+1lunQhYp4adgxhwf6ZZPfUjtGrFwYw7rPXYuyf d8Mw== MIME-Version: 1.0 X-Received: by 10.224.103.197 with SMTP id l5mr8237652qao.69.1396540613727; Thu, 03 Apr 2014 08:56:53 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Thu, 3 Apr 2014 08:56:53 -0700 (PDT) Date: Thu, 3 Apr 2014 23:56:53 +0800 Message-ID: From: chong feng To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c1bdee321b8e04f6257343 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XVdxNZGwh4w1f-fYAfxt9CV__WE Subject: [netmod] YANG1.1 issue: add filter type to pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:57:12 -0000 --001a11c1bdee321b8e04f6257343 Content-Type: text/plain; charset=ISO-8859-1 Hi all, YANG1.0 can not express filter type,such as include or exclude,so ,YANG1.1 can add 'filter' statement as sub statement of pattern. For example, leaf a { type string { pattern p1 { filter exclude; } } } 'filter' statement has an argument 'type', this argument accept'include' and 'exclude' as valid value,default is 'include'. --001a11c1bdee321b8e04f6257343 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi all,
    =A0 =A0 =A0YANG1.0 can not express filter type= ,such as include or exclude,so ,YANG1.1 can add 'filter' statement = as sub statement of pattern.
    For example,
    =A0 =A0 =A0le= af a {
    =A0 =A0 =A0 =A0 =A0 =A0 type string {
    =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0pattern p1 {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 filter exclude;
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
    =A0 =A0 =A0 =A0 =A0 =A0 = }
    =A0 =A0 =A0}

    'filter' statement has an argument 'type= 9;, this argument accept'include' and 'exclude' as valid va= lue,default is 'include'.
    --001a11c1bdee321b8e04f6257343-- From nobody Thu Apr 3 10:49:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA201A0218 for ; Thu, 3 Apr 2014 10:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPmH-gDM5aFd for ; Thu, 3 Apr 2014 10:49:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B01801A020E for ; Thu, 3 Apr 2014 10:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38993; q=dns/txt; s=iport; t=1396547338; x=1397756938; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=b7WEnKOMidoaDaZCjGlk5B3GnqAn2PvNY2TRSKJzN6c=; b=kpZlaCWUBKzW0liRpfjs7aO0pZzicclPpxJDVArJHFRk7CwdoDJBFI/5 gCt+m3fFf0prD/xfeBuNQQz3jL6CcqpQHu7EZQ2yqvzvnE7sF3kdwhxJT CL5FLIKQAPwNw+p9hZ7Dr6c2wNZ83LfnUvfUd45mV5JllltkP4tfqxMw2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAOydPVOtJA2N/2dsb2JhbABYgkJEgRKtAJZ3gR8WdIIlAQIEgQsBCBEDAQIhAQY5EwEJCAIEARKHZQMRzycXjFeCCRcBhDgBA4dnjw2BZ4dehRGFT4Mwgis X-IronPort-AV: E=Sophos;i="4.97,788,1389744000"; d="scan'208,217";a="315002382" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2014 17:48:57 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s33HmvDP011059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Apr 2014 17:48:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 12:48:56 -0500 From: "Lisa Huang (yihuan)" To: steve cheng , "netmod@ietf.org" Thread-Topic: [netmod] Suggestions for draft-huang-netmod-acl-03.txt Thread-Index: AQHPS3pijR1Q1sdM+0mIH/ybqDU4lJr9Um0AgAJUYACAAGqsAA== Date: Thu, 3 Apr 2014 17:48:55 +0000 Message-ID: In-Reply-To: <1396499226.70452.YahooMailNeo@web162501.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.117.113] Content-Type: multipart/alternative; boundary="_000_CF62E003118976yihuanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Cg6vKjODsCBbXFBkU_LTYJCoqPE Subject: Re: [netmod] Suggestions for draft-huang-netmod-acl-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 17:49:07 -0000 --_000_CF62E003118976yihuanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [Steve] Agree, prefix list is different from access list. Well many existin= g routing applications do use ACL (not prefix-list) widely. For cases that routing application use the full ACL, most likely ACL = is referred by name. A match leaf or leaf-list can be defined in YANG to se= rve the purpose. leaf match { type "spf:spf-ref"; } [Steve] Logically it(debugging output) could be as simple as this, debugging feature filter =3D=3D=3D=3D> only debugging msg w= ith ACL defined src/dest ip/port will be displayed. Do you mean CLI configuration like the following and try to find out= how to use the existing stateless-pf.yang data model to model this case? ip access-list extended host1 permit ip any host 10.1.1.1 log permit ip host 10.1.1.1 any log debug access-list host1 From: steve cheng > Reply-To: steve cheng > Date: Wednesday, April 2, 2014 9:27 PM To: Microsoft Office User >, "net= mod@ietf.org" > Subject: Re: [netmod] Suggestions for draft-huang-netmod-acl-03.txt Hi Lisa, Thanks for your reply. Please see inline with [Steve]. thanks, Steve On Tuesday, April 1, 2014 4:52 PM, Lisa Huang (yihuan) > wrote: Steve, Comments in line. --Lisa From: steve cheng > Reply-To: steve cheng > Date: Saturday, March 29, 2014 11:11 AM To: "netmod@ietf.org" > Subject: [netmod] Suggestions for draft-huang-netmod-acl-03.txt Hi Lisa/Alex/Andy, I saw current draft doesn't cover how SPF (ACL) is applied on an interface = or other client applications. Section 3.3.4 of the draft briefly covers how to apply SPF(ACL) to = interface and also gives an example of how to attach an SPF to an interfac= e. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We typically call these SPF(ACL) on an interface for packet filtering as Se= curity ACL. For example, interface foo SPF(ACL) bar ingress/egress Would it make sense to create a new draft? Yes. You could create a new module which augment interface module an= d add SPF(ACL) leaf list. Section 3.3.4 has an example of that. [Steve] OK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Another kind of widely deployed SPF(ACL) is in other client applications. Q= oS, PBR, and routing protocols such as OSPF/BGP are some examples. * For QoS/PBR/other policy based applications, it's used for classifica= tion. For example QoS, * class foo: match SPF (ACL), * policy bar: match class foo, rate limiting * policy bar is applied on an interface ingress/egress One way is: Import stateless-pf { prefix "spf"; } =85 List class { Key "name"; Leaf "name" { =85 } Leaf-list match { type "spf:spf-ref"; } } [Steve] we can discuss more about this if QoS/PBR YANG modeling is in the p= icture in the future. Absolutely. * For routing protocols, it's used for route/prefix filtering (not pack= et filtering). prefix filter is different from access list since it has less filter= ing options and don't distinguish packet source and destination. Since both= filter has similarity, prefix filtering can reuse most of the grouping def= inition in SPF(ACL). [Steve] Agree, prefix list is different from access list. Well many existin= g routing applications do use ACL (not prefix-list) widely. * some other applications can simply use ACL (SPF) to filter out debugg= ing output. Is this the use case described in CLI? access-list 101 permit tcp any host 192.168.35.1 range 20 21access-list 102= permit tcp host 192.168.35.1 any established interface ethernet 0access-group 101 outaccess-group 102 in In this case, the configuration is a single unnamed ACE in ACL but ACE name= is a mandatory leaf in the draft. The implementation is not in scope of th= e draft, but one way to implement is to add an adapter of netconf engine an= d backend. The job of the adapter is to map name based ACE(netconf config) = to single no name ACE(system) back and forth. List access-group { Key "spf-name"; Leaf "spf-name" { type "spf:spf-ref"; } Leaf dirction { type enumeration { Enum "in"; Enum "out"; } } } [Steve] No, this is not the case. Logically it could be as simple as this, debugging feature filter =3D=3D=3D=3D> only debugging msg w= ith ACL defined src/dest ip/port will be displayed. Any suggestion on how to deal with them? cheers, Steve Cheng --_000_CF62E003118976yihuanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7185CF18F9EEDE43B6AC1A7CBACF21E7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    [Ste= ve] Agree, prefix list is different from access list. Well many existing routing applications do use ACL (not prefi= x-list) widely. 
    <= ;Lisa>For cases that routing application use the full ACL, most likely ACL is referred by name. A match leaf or leaf-li= st can be defined in YANG to serve the purpose.
    leaf match {

    [Steve] Logically it(= debugging output) could be as simple as this, 
    debugging feature fil= ter <ACL>           =3D=3D=3D=3D> only de= bugging msg with ACL defined src/dest ip/port will be displayed.
    <Lisa> Do you m= ean CLI configuration like the following and try to find out how to use the= existing stateless-pf.yang data model to model this case?

    ip access-list extended host1

      permit ip any host 10.1.1.1 log

      permit ip host 10.1.1.1 any log

     

    debug access-list host1



    =



    From: steve cheng <scheng98_98@yahoo.com>
    Reply-To: steve cheng <scheng98_98@yahoo.com>
    Date: Wednesday, April 2, 2014 9:27= PM
    To: Microsoft Office User <yihuan@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
    Subject: Re: [netmod] Suggestions f= or draft-huang-netmod-acl-03.txt


    Thanks for your reply. 

    Please see inline with [Steve].

    thanks,

    Steve
    On Tuesday, April 1, 2014 = 4:52 PM, Lisa Huang (yihuan) <yihuan= @cisco.com> wrote:
    Steve, Comments in line. --Lisa

    From: steve cheng <scheng98_98@yahoo.com><= br clear=3D"none"> Reply-To: steve cheng <scheng98_98@yahoo.com>
    Date: Saturday, March 29, 2014 11:= 11 AM
    To: "
    netmod@ietf.org" <netmod@ietf.org>
    Subject: [netmod] Suggestions for = draft-huang-netmod-acl-03.txt

    Hi Lisa/Alex/Andy,

    I saw current draft doesn't cover how SPF (ACL) is applied on an interface = or other client applications.

    <Lisa> Section 3.3.4 of the draft briefly covers how to app= ly SPF(ACL)  to interface  and also gives an example of how = to attach an SPF to an interface.

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

    We typically call these SPF(ACL) on an interface for packet filtering as Se= curity ACL. For example,
    interface foo
        SPF(ACL) bar ingress/egress

    Would it make sense to create a new draft?
    <Lisa> Yes. You could create a new module which augment interfac= e module and add SPF(ACL) leaf list. Section 3.3.4 has an example of that.&= nbsp;

    [Steve] OK
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

    Another kind of widely deployed SPF(ACL) is in other client applications. Q= oS, PBR, and routing protocols such as OSPF/BGP are some examples.
    • For QoS/PBR/other policy based applications, it's used for classificati= on. For example QoS,
      • class foo: match SPF (ACL),
      • policy bar: match class foo, rate limiting
      • policy bar is a= pplied on an interface ingress/egress
    <Lisa>One way is:
    Import stateless-pf {
    prefix "spf";
    }
    =85
    List class {
    Key "name";
    Leaf "name" {
    =85
    }
    Leaf-list match {
    type "spf:spf-ref";
    }
    }

    [Steve] we can discuss more about this if QoS/PBR YANG modeling is in = the picture in the future.
    <Lisa> Absolutely.<= /div>
    • For routing protocols, it's used for route/prefix filtering (not packet= filtering).
    <Lisa> prefix filter is different from access list since it has = less filtering options and don't distinguish packet source and destination.= Since both filter has similarity, prefix filtering can reuse most of the g= rouping definition in SPF(ACL).
    [Steve] Agree, prefix list is different from access list. Well many ex= isting routing applications do use ACL (not prefix-list) widely. 

    • some other applications can simply use ACL (SPF) to filter out debuggin= g output.
    <Lisa>Is this the use case described in CLI?
    access-list 101 permit tcp any host 192.168.=
    35.1 range 20 21access-list 102 pe=
    rmit tcp host 192.168.35.1 any established

    interface ethernet 0access-group 101 outaccess-group 102 in
    In =
    this case, the configuration is a single unnamed ACE in ACL but ACE name is=
     a mandatory leaf in the draft. The implementation is not in scop=
    e of the draft, but one way to implement is to add an adapter of netconf en=
    gine and backend. The job of the adapter is to map name based ACE(netconf c=
    onfig) to single no name ACE(system) back and forth. 
    List access-group {
    Key "spf-name";
    Leaf "spf-name" {
    = type "spf:spf-ref";
    }
    Leaf  dirction = {
    type enumeration {
    Enum "in";=
    Enum "out";
    }
    }
    }
    [Steve] No, this is not= the case. Logically it could be as simple as this, 
    debugging feature filte= r <ACL>           =3D=3D=3D=3D> only debu= gging msg with ACL defined src/dest ip/port will be displayed.




    Any suggestion on how to deal with them?


    cheers,

    Steve Cheng




    --_000_CF62E003118976yihuanciscocom_-- From nobody Thu Apr 3 13:57:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7181A01DD for ; Thu, 3 Apr 2014 13:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isJjlKkGo2dU for ; Thu, 3 Apr 2014 13:57:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFD61A0197 for ; Thu, 3 Apr 2014 13:57:08 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id E2836384006; Thu, 3 Apr 2014 22:56:59 +0200 (CEST) Date: Thu, 03 Apr 2014 22:56:59 +0200 (CEST) Message-Id: <20140403.225659.536777485.mbj@tail-f.com> To: fengchongllly@gmail.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yx8dZt_-47jyNcSy08hQVmC75a0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue: add filter type to pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:57:13 -0000 Hi, I think this is covered by Y23. I rephrased that issue, and added your proposal as Y23-02. /martin chong feng wrote: > YANG1.0 can not express filter type,such as include or exclude,so > ,YANG1.1 can add 'filter' statement as sub statement of pattern. > For example, > leaf a { > type string { > pattern p1 { > filter exclude; > } > > } > } > > 'filter' statement has an argument 'type', this argument accept'include' From nobody Thu Apr 3 20:19:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D6C1A0349 for ; Thu, 3 Apr 2014 20:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_F8VsSgmhwO for ; Thu, 3 Apr 2014 20:19:11 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAC51A008F for ; Thu, 3 Apr 2014 20:19:11 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so2792593pbb.36 for ; Thu, 03 Apr 2014 20:19:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=B46hGuyIGsCnQanNevLcQmmu9Rd70U7FJW0FisWCREo=; b=iev8E+gApnhd/m7fgrZMb57sowLE9xKABANSMSJivfwxQ4xSEm8unbosLkywD+g302 iEG8SuW3Dnkq4rDKwnPYjFeEdTyyfW3WNGW+HwK+5nskhhZxbvQ+Q2epWvkXyzjCDn5b nSjYc3Ls0lcnFVWe+z5P+ZLi6XEjiZezxonP0VQ0xe8Z5N8xPEDGlglfBJ3UBSpktufv aRp1Kzq8YdVWwUl+xxQTsuId60VZFmMB/I4hFSL3odKp51KU/ZMk6F5dT54Dtp2AeSX4 hrMVMy0LaToj9g4ymUSVm3r5OPzShLFLrFgPBWsfiNdZyAGX5GZTGqQkVUKT/a8HaRzc IIIg== X-Gm-Message-State: ALoCoQmd7Ym0MUBZsrLnlttfu3LDkIQjgLpghGgRFlFXkQIZmJHXS9n2rHf47tCQLYhh1usZAPHx MIME-Version: 1.0 X-Received: by 10.66.192.225 with SMTP id hj1mr11972783pac.142.1396581545865; Thu, 03 Apr 2014 20:19:05 -0700 (PDT) Received: by 10.68.163.99 with HTTP; Thu, 3 Apr 2014 20:19:05 -0700 (PDT) Date: Thu, 3 Apr 2014 20:19:05 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc9146f1084804f62efa7f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/x48eUT15FufihMwDSNEOd2b6w5o Subject: [netmod] augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 03:19:16 -0000 --047d7bdc9146f1084804f62efa7f Content-Type: text/plain; charset=ISO-8859-1 Hi, I am trying to work through a customer-found bug. When the external augment leafref path is validated, the parser does not find the 'type' leaf in the 'name' path-stmt. (See below). Notice that the ../type part of the expression has no prefix. In YANG that means it defaults to the 'config' module. But the odl-sal-netconf-connector-cfg module is augmenting the dom-register container with 'type' and 'name' leafs that are in its own namespace, not in the config namespace. The XPath parser does not think 'type' is a valid child node there, since the module name is wrong. Is there a way the 'name' path-expr can be written so it will match the namespace for the expanded grouping? Is this a general problem with XPath inside groupings (i.e., the target namespace of the final expanded objects is not known)? Is this a YANG 1.1 issue? Andy >From config.yang: grouping service-ref { description "Type of references to a particular service instance. This type can be used when defining module configuration to refer to a particular service instance. Containers using this grouping should not define anything else. The run-time implementation is expected to inject a reference to the service as the value of the container."; leaf type { description "Type of the service being referenced. Users of this grouping should refine this leaf with required-identity pointing to the actual service-type which is actually required."; mandatory true; type service-type-ref; } leaf name { mandatory true; type leafref { path "/config:services/config:service[config:type=current()/../type]/config:instance/config:name"; } } } >From odl-sal-netconf-connector-cfg.yang: container dom-registry { uses config:service-ref { refine type { mandatory true; config:required-identity dom:dom-broker-osgi-registry; } } } --047d7bdc9146f1084804f62efa7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I am trying to work through a customer-found bug.
    When the ext= ernal augment leafref path is validated, the
    parser does not = find the 'type' leaf in the 'name' path-stmt.
    (See below).

    Notice= that the ../type part of the expression
    has no prefix. =A0In YANG that means it defau= lts to
    the 'config&= #39; module.

    But = the odl-sal-netconf-connector-cfg module is
    augmenting the d= om-register container with 'type'
    and 'name' leafs that are in its own= namespace,
    not in the confi= g namespace. =A0The XPath parser
    does not think 'type' is a valid child node t= here,
    since the module= name is wrong.

    I= s there a way the 'name' path-expr can be written so it will match<= /div>
    the namespace fo= r the expanded grouping?

    Is this a general problem with XPath inside groupings (i.e.,
    the target namespace of t= he final expanded objects is not known)?
    Is this a YANG 1.1 issue?


    Andy


    From config.yang:<= /div>

    =A0 =A0 grouping = service-ref {
    =A0 =A0 =A0 =A0 description
    =A0 =A0 =A0 = =A0 =A0 =A0 "Type of references to a particular service instance. This= type
    =A0 =A0 =A0 =A0 =A0 =A0 =A0can be used when defining module configurat= ion to refer to a
    =A0 =A0 =A0 =A0 =A0 =A0 =A0particular service i= nstance. Containers using this grouping
    =A0 =A0 =A0 =A0 =A0 =A0 = =A0should not define anything else. The run-time implementation
    =A0 =A0 =A0 =A0 =A0 =A0 =A0is expected to inject a reference to the se= rvice as the value
    =A0 =A0 =A0 =A0 =A0 =A0 =A0of the container.&q= uot;;

    =A0 =A0 =A0 =A0 leaf type {
    =A0 = =A0 =A0 =A0 =A0 =A0 description
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &= quot;Type of the service being referenced. Users of this grouping
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should refine this leaf with requir= ed-identity pointing to
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the ac= tual service-type which is actually required.";

    =A0 =A0 =A0 =A0 =A0 =A0 mandatory true;
    =A0 =A0 =A0 =A0 =A0 =A0 type service-type-ref;
    =A0 =A0 =A0 = =A0 }

    =A0 =A0 =A0 =A0 leaf name {
    =A0 = =A0 =A0 =A0 =A0 =A0 mandatory true;
    =A0 =A0 =A0 =A0 =A0 =A0 type = leafref {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 path "/config:serv= ices/config:service[config:type=3Dcurrent()/../type]/config:instance/config= :name";
    =A0 =A0 =A0 =A0 =A0 =A0 }
    =A0 =A0 =A0 =A0 }
    =A0 = =A0 }


    <= /div>
    >From odl-sal-netconf-connector-cfg.yang:

    =A0 =A0 =A0 =A0 =A0 =A0 container dom-registry {
    <= font face=3D"arial, sans-serif">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uses config= :service-ref {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 refine type {
    =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mandatory true;
    <= font face=3D"arial, sans-serif">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 config:required-identity dom:dom-broker-osgi-registry;
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 }
    =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 }
    =A0 =A0 = =A0 =A0 =A0 =A0 }

    =
    --047d7bdc9146f1084804f62efa7f-- From nobody Thu Apr 3 22:34:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF901A00B3 for ; Thu, 3 Apr 2014 22:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoYfyn2V3wjk for ; Thu, 3 Apr 2014 22:34:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id DD6A81A0046 for ; Thu, 3 Apr 2014 22:34:41 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 08DFF476C11; Fri, 4 Apr 2014 07:34:36 +0200 (CEST) Date: Fri, 04 Apr 2014 07:34:35 +0200 (CEST) Message-Id: <20140404.073435.465375045.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tkkCArkZ7eHG-UMSV0Y7oTYyxm4 Cc: netmod@ietf.org Subject: Re: [netmod] augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 05:34:47 -0000 Andy Bierman wrote: > Hi, > > I am trying to work through a customer-found bug. > When the external augment leafref path is validated, the > parser does not find the 'type' leaf in the 'name' path-stmt. > (See below). > > Notice that the ../type part of the expression > has no prefix. In YANG that means it defaults to > the 'config' module. No, inside a grouping, unprefixed names resolve to the module where the grouping is (eventually) instantiated. >From 6.4.1: o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping, that namespace is affected by where the grouping is used (see Section 7.12). /martin > But the odl-sal-netconf-connector-cfg module is > augmenting the dom-register container with 'type' > and 'name' leafs that are in its own namespace, > not in the config namespace. The XPath parser > does not think 'type' is a valid child node there, > since the module name is wrong. > > Is there a way the 'name' path-expr can be written so it will match > the namespace for the expanded grouping? > > Is this a general problem with XPath inside groupings (i.e., > the target namespace of the final expanded objects is not known)? > Is this a YANG 1.1 issue? > > > Andy > > > >From config.yang: > > grouping service-ref { > description > "Type of references to a particular service instance. This type > can be used when defining module configuration to refer to a > particular service instance. Containers using this grouping > should not define anything else. The run-time implementation > is expected to inject a reference to the service as the value > of the container."; > > leaf type { > description > "Type of the service being referenced. Users of this > grouping > should refine this leaf with required-identity pointing to > the actual service-type which is actually required."; > > mandatory true; > type service-type-ref; > } > > leaf name { > mandatory true; > type leafref { > path > "/config:services/config:service[config:type=current()/../type]/config:instance/config:name"; > } > } > } > > > >From odl-sal-netconf-connector-cfg.yang: > > container dom-registry { > uses config:service-ref { > refine type { > mandatory true; > config:required-identity > dom:dom-broker-osgi-registry; > } > } > } From nobody Fri Apr 4 01:19:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACC01A03BD for ; Fri, 4 Apr 2014 01:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_102=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcCKexPdlt_S for ; Fri, 4 Apr 2014 01:19:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B2D691A0423 for ; Fri, 4 Apr 2014 01:19:15 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 855F9384005; Fri, 4 Apr 2014 10:19:09 +0200 (CEST) Date: Fri, 04 Apr 2014 10:19:09 +0200 (CEST) Message-Id: <20140404.101909.333135937.mbj@tail-f.com> To: fengchongllly@gmail.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gLZWZ8AwX3RZnk46x80PqJhxtc0 Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: add expression of patterns' relation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:19:24 -0000 Added as Y32. /martin chong feng wrote: > It's not possible to express the relation of patterns. For example, > leaf a { > type string { > pattern p1; > pattern p2; > pattern p3; > } > } > > It's not possible to express ( p1 | p3) & p2. > > So, YANG1.1 can add 3 statements:patterns , regex and relation > to express this relation. > > 'patterns' statement as type(string)'s sub statement, and for compatible, > 'pattern' statement will be reserved > > > 'patterns' statement has no argument and has some sub statements listed > below: > +---------------+--------------+ > | substatement | cardinality | > +---------------+--------------+ > | description | 0..1 | > | error-app-tag | 0..1 | > | error-message | 0..1 | > | reference | 0..1 | > | pattern | 0..n | > | relation | 0..1 | > +---------------+--------------+ > > 'pattern' statement is a sub statement of 'patterns' and is not the same to > the 'pattern' statement as the sub statement of type(string). > So, it's called new 'pattern' statement. > the new 'pattern' statement has a argument 'name',it's not regular > expression,it's just a pattern identifier.The new 'pattern' statement > has some sub statements listed below: > +---------------+--------------+ > | substatement | cardinality | > +---------------+--------------+ > | description | 0..1 | > | error-app-tag | 0..1 | > | error-message | 0..1 | > | reference | 0..1 | > | regex | 1 | > +---------------+--------------+ > 'regex' statement has an argument 'expression',this argument is a regular > expression,and 'regex' statement has no sub statements. > > 'realation' statement has an argument "expression", this argument is a > logical expression,such as (p1 | p2)&p3,etc. And this statement has > no sub statement. > > For example: > > leaf a { > type string { > patterns { > pattern p1 { > regex "[a-z]"; > } > pattern p2 { > regex "[0-9]" > } > relation "(p1 | p2)"; > } > pattern "abc"; > > } > } From nobody Fri Apr 4 01:35:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77C31A043F for ; Fri, 4 Apr 2014 01:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi8MkLWTtSqI for ; Fri, 4 Apr 2014 01:35:30 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id A44D91A0411 for ; Fri, 4 Apr 2014 01:35:30 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id 63so3403qgz.8 for ; Fri, 04 Apr 2014 01:35:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DrLw4ELixgXFM0gaWCpdAFzRIuhyQSHtpcwhZf9pNqQ=; b=PbPGnFU/+DAO4oYRwzv+0chQ4FB1kR8eTdktDOfinemVMptpYvkZQi1dHEZjqz1qJA C+7HX8buS8GrG/C9tmlGLDxo9/W8Fjmf3KHsFPXvNS9xcvcpR12ut7DVO1BwzI7hbSR0 Am3G4cn0Sj5PeoAr6hKNfKfSh38ukxPm3XjaKfEzxEI+8tCiK0H1RnjtJI+yts/tiwH4 /JmPTvzquFQMas7Pa2tRbDvtohNxEoo/EaatdmhDvZKvHNs28syf1AydGB3Q0IgKPwAL evMzyVJGgZYUcf1dmct5AZXOR84+jR8LfNpf5AaieHJiE2RpZVHOGHxx2AwJjm5NtIfW WIzg== X-Gm-Message-State: ALoCoQl/R3FVrKRM4nKDYU6Hdn5yCQoqsaUSlKOyaIdtNNQ4l+6O2/U/FhfqMbwLlENtkBV+0rv7 MIME-Version: 1.0 X-Received: by 10.224.112.6 with SMTP id u6mr12737941qap.78.1396600525948; Fri, 04 Apr 2014 01:35:25 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 4 Apr 2014 01:35:25 -0700 (PDT) In-Reply-To: <20140404.073435.465375045.mbj@tail-f.com> References: <20140404.073435.465375045.mbj@tail-f.com> Date: Fri, 4 Apr 2014 01:35:25 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2e8483e1db304f63366ce Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZI4cPOpo7BSuhjprNgxpk9GYh7U Cc: "netmod@ietf.org" Subject: Re: [netmod] augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:35:34 -0000 --001a11c2e8483e1db304f63366ce Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 3, 2014 at 10:34 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I am trying to work through a customer-found bug. > > When the external augment leafref path is validated, the > > parser does not find the 'type' leaf in the 'name' path-stmt. > > (See below). > > > > Notice that the ../type part of the expression > > has no prefix. In YANG that means it defaults to > > the 'config' module. > > No, inside a grouping, unprefixed names resolve to the module where > the grouping is (eventually) instantiated. > > From 6.4.1: > > o Names without a namespace prefix belong to the same namespace as > the identifier of the current node. Inside a grouping, that > namespace is affected by where the grouping is used (see > Section 7.12). > > OK -- except the path-expr is considered a schema node identifier (6.5) not an XPath expression (6.4.1) So this text in 6.5 seems relevant: References to identifiers defined in external modules MUST be qualified with appropriate prefixes, and references to identifiers defined in the current module and its submodules MAY use a prefix. The text in 6.4.1 does not seem to also apply to sec. 6.5. > > > /martin > > > Andy > > > But the odl-sal-netconf-connector-cfg module is > > augmenting the dom-register container with 'type' > > and 'name' leafs that are in its own namespace, > > not in the config namespace. The XPath parser > > does not think 'type' is a valid child node there, > > since the module name is wrong. > > > > Is there a way the 'name' path-expr can be written so it will match > > the namespace for the expanded grouping? > > > > Is this a general problem with XPath inside groupings (i.e., > > the target namespace of the final expanded objects is not known)? > > Is this a YANG 1.1 issue? > > > > > > Andy > > > > > > >From config.yang: > > > > grouping service-ref { > > description > > "Type of references to a particular service instance. This > type > > can be used when defining module configuration to refer to a > > particular service instance. Containers using this grouping > > should not define anything else. The run-time implementation > > is expected to inject a reference to the service as the > value > > of the container."; > > > > leaf type { > > description > > "Type of the service being referenced. Users of this > > grouping > > should refine this leaf with required-identity pointing > to > > the actual service-type which is actually required."; > > > > mandatory true; > > type service-type-ref; > > } > > > > leaf name { > > mandatory true; > > type leafref { > > path > > > "/config:services/config:service[config:type=current()/../type]/config:instance/config:name"; > > } > > } > > } > > > > > > >From odl-sal-netconf-connector-cfg.yang: > > > > container dom-registry { > > uses config:service-ref { > > refine type { > > mandatory true; > > config:required-identity > > dom:dom-broker-osgi-registry; > > } > > } > > } > --001a11c2e8483e1db304f63366ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Thu, Apr 3, 2014 at 10:34 PM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    Andy Bierman <and= y@yumaworks.com> wrote:
    > Hi,
    >
    > I am trying to work through a customer-found bug.
    > When the external augment leafref path is validated, the
    > parser does not find the 'type' leaf in the 'name' pat= h-stmt.
    > (See below).
    >
    > Notice that the ../type part of the expression
    > has no prefix. =A0In YANG that means it defaults to
    > the 'config' module.

    No, inside a grouping, unprefixed names resolve to the module where
    the grouping is (eventually) instantiated.

    >From 6.4.1:

    =A0 =A0o =A0Names without a namespace prefix belong to the same namespace a= s
    =A0 =A0 =A0 the identifier of the current node. =A0Inside a grouping, that<= br> =A0 =A0 =A0 namespace is affected by where the grouping is used (see
    =A0 =A0 =A0 Section 7.12).



    OK -- except the path-e= xpr is considered a schema node identifier (6.5)
    not an XPath exp= ression (6.4.1) So this text in 6.5 seems relevant:

       References to identifiers defined in external modules MUST be
       qualified with appropriate prefixes, and references to identifiers
       defined in the current module and its submodules MAY use a prefix.
    

    The text in 6.4.1 does not seem to also app= ly to sec. 6.5.

    =A0


    /martin



    Andy
    =A0

    > But the odl-sal-netconf-connector-cfg module is
    > augmenting the dom-register container with 'type'
    > and 'name' leafs that are in its own namespace,
    > not in the config namespace. =A0The XPath parser
    > does not think 'type' is a valid child node there,
    > since the module name is wrong.
    >
    > Is there a way the 'name' path-expr can be written so it will = match
    > the namespace for the expanded grouping?
    >
    > Is this a general problem with XPath inside groupings (i.e.,
    > the target namespace of the final expanded objects is not known)?
    > Is this a YANG 1.1 issue?
    >
    >
    > Andy
    >
    >
    > >From config.yang:
    >
    > =A0 =A0 grouping service-ref {
    > =A0 =A0 =A0 =A0 description
    > =A0 =A0 =A0 =A0 =A0 =A0 "Type of references to a particular servi= ce instance. This type
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0can be used when defining module configurat= ion to refer to a
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0particular service instance. Containers usi= ng this grouping
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0should not define anything else. The run-ti= me implementation
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0is expected to inject a reference to the se= rvice as the value
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0of the container.";
    >
    > =A0 =A0 =A0 =A0 leaf type {
    > =A0 =A0 =A0 =A0 =A0 =A0 description
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Type of the service being refere= nced. Users of this
    > grouping
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should refine this leaf with requir= ed-identity pointing to
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the actual service-type which is ac= tually required.";
    >
    > =A0 =A0 =A0 =A0 =A0 =A0 mandatory true;
    > =A0 =A0 =A0 =A0 =A0 =A0 type service-type-ref;
    > =A0 =A0 =A0 =A0 }
    >
    > =A0 =A0 =A0 =A0 leaf name {
    > =A0 =A0 =A0 =A0 =A0 =A0 mandatory true;
    > =A0 =A0 =A0 =A0 =A0 =A0 type leafref {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 path
    > "/config:services/config:service[config:type=3Dcurrent()/../type]= /config:instance/config:name";
    > =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 =A0 }
    > =A0 =A0 }
    >
    >
    > >From odl-sal-netconf-connector-cfg.yang:
    >
    > =A0 =A0 =A0 =A0 =A0 =A0 container dom-registry {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uses config:service-ref {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 refine type {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mandatory true;
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 config:required-identi= ty
    > dom:dom-broker-osgi-registry;
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 =A0 =A0 =A0 }

    --001a11c2e8483e1db304f63366ce-- From nobody Fri Apr 4 01:36:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF31A03BD for ; Fri, 4 Apr 2014 01:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsHACpCrv5nB for ; Fri, 4 Apr 2014 01:36:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0981A0434 for ; Fri, 4 Apr 2014 01:36:15 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id B8B9F37C33F for ; Fri, 4 Apr 2014 10:36:10 +0200 (CEST) Date: Fri, 04 Apr 2014 10:36:10 +0200 (CEST) Message-Id: <20140404.103610.493044772.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/f9XNJUpiNOB6DJgJlm3Wdvl658s Subject: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:36:20 -0000 Hi, My first reaction to this proposal is that it seems a bit complex. I can see the theoretical problem, but I have never seen this in a real module. In most cases, this can be solved with the current mechanism. For example: (p1 | p2) & p3 can be solved by: pattern "p1 | p2"; pattern "p3"; p1 | (p2 & p3) is trickier. So I am not sure the additional complexity is worth it. /martin From nobody Fri Apr 4 01:41:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72621A0411 for ; Fri, 4 Apr 2014 01:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxpyF4yr1LTO for ; Fri, 4 Apr 2014 01:41:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 69AB81A0115 for ; Fri, 4 Apr 2014 01:41:44 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id F04C237C33F; Fri, 4 Apr 2014 10:41:38 +0200 (CEST) Date: Fri, 04 Apr 2014 10:41:38 +0200 (CEST) Message-Id: <20140404.104138.431972199.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140404.073435.465375045.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V43uirzq8FK0wzSu31bQyHnUWNY Cc: netmod@ietf.org Subject: Re: [netmod] augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:41:49 -0000 Andy Bierman wrote: > On Thu, Apr 3, 2014 at 10:34 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > Hi, > > > > > > I am trying to work through a customer-found bug. > > > When the external augment leafref path is validated, the > > > parser does not find the 'type' leaf in the 'name' path-stmt. > > > (See below). > > > > > > Notice that the ../type part of the expression > > > has no prefix. In YANG that means it defaults to > > > the 'config' module. > > > > No, inside a grouping, unprefixed names resolve to the module where > > the grouping is (eventually) instantiated. > > > > From 6.4.1: > > > > o Names without a namespace prefix belong to the same namespace as > > the identifier of the current node. Inside a grouping, that > > namespace is affected by where the grouping is used (see > > Section 7.12). > > > > > > OK -- except the path-expr is considered a schema node identifier (6.5) > not an XPath expression (6.4.1) No, path is not a schema node identifier. See section 9.9.2, where it is defined as a restricted XPath expression: The "path" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: So it does explicitly refer to 6.4.1. /martin From nobody Fri Apr 4 01:47:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4121B1A0458 for ; Fri, 4 Apr 2014 01:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_102=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZHhDGqsjHm1 for ; Fri, 4 Apr 2014 01:47:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 351531A0454 for ; Fri, 4 Apr 2014 01:47:15 -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 4ED6B574005; Fri, 4 Apr 2014 10:47:10 +0200 (CEST) Message-ID: <533E718E.3050603@tail-f.com> Date: Fri, 04 Apr 2014 10:47:10 +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: Martin Bjorklund References: <20140404.101909.333135937.mbj@tail-f.com> In-Reply-To: <20140404.101909.333135937.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bng2wmpWevVJSSIlenGfe9A9sMg Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: add expression of patterns' relation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:47:21 -0000 On 2014-04-04 10:19, Martin Bjorklund wrote: > Added as Y32. Hm, but the problem statement isn't correct, is it? Multliple patterns are ANDed per 6020, and OR is just standard regexp "branching". I.e. ( p1 | p3) & p2 is expressed as type string { pattern p1|p3; pattern p2; } (of course with actual pattern strings p1 and p3 are probably quoted, and the vertical bar needs to be inside the single pair of quotes for the combination). Am I missing something? --Per > /martin > > > chong feng wrote: >> It's not possible to express the relation of patterns. For example, >> leaf a { >> type string { >> pattern p1; >> pattern p2; >> pattern p3; >> } >> } >> >> It's not possible to express ( p1 | p3) & p2. >> >> So, YANG1.1 can add 3 statements:patterns , regex and relation >> to express this relation. >> >> 'patterns' statement as type(string)'s sub statement, and for compatible, >> 'pattern' statement will be reserved >> >> >> 'patterns' statement has no argument and has some sub statements listed >> below: >> +---------------+--------------+ >> | substatement | cardinality | >> +---------------+--------------+ >> | description | 0..1 | >> | error-app-tag | 0..1 | >> | error-message | 0..1 | >> | reference | 0..1 | >> | pattern | 0..n | >> | relation | 0..1 | >> +---------------+--------------+ >> >> 'pattern' statement is a sub statement of 'patterns' and is not the same to >> the 'pattern' statement as the sub statement of type(string). >> So, it's called new 'pattern' statement. >> the new 'pattern' statement has a argument 'name',it's not regular >> expression,it's just a pattern identifier.The new 'pattern' statement >> has some sub statements listed below: >> +---------------+--------------+ >> | substatement | cardinality | >> +---------------+--------------+ >> | description | 0..1 | >> | error-app-tag | 0..1 | >> | error-message | 0..1 | >> | reference | 0..1 | >> | regex | 1 | >> +---------------+--------------+ >> 'regex' statement has an argument 'expression',this argument is a regular >> expression,and 'regex' statement has no sub statements. >> >> 'realation' statement has an argument "expression", this argument is a >> logical expression,such as (p1 | p2)&p3,etc. And this statement has >> no sub statement. >> >> For example: >> >> leaf a { >> type string { >> patterns { >> pattern p1 { >> regex "[a-z]"; >> } >> pattern p2 { >> regex "[0-9]" >> } >> relation "(p1 | p2)"; >> } >> pattern "abc"; >> >> } >> } > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 4 02:14:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65A1A001D for ; Fri, 4 Apr 2014 02:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GR0hTSLTdHKH for ; Fri, 4 Apr 2014 02:14:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2EA1A0118 for ; Fri, 4 Apr 2014 02:14:00 -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 691A6476885; Fri, 4 Apr 2014 11:13:55 +0200 (CEST) Message-ID: <533E77D3.4030005@tail-f.com> Date: Fri, 04 Apr 2014 11:13:55 +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: Martin Bjorklund References: <20140404.103610.493044772.mbj@tail-f.com> In-Reply-To: <20140404.103610.493044772.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ntdxHy1SvZ4JgeDPM79Fkm4a_So Cc: netmod@ietf.org Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:14:05 -0000 On 2014-04-04 10:36, Martin Bjorklund wrote: > Hi, > > My first reaction to this proposal is that it seems a bit > complex. I can see the theoretical problem, but I have never seen > this in a real module. In most cases, this can be solved with the > current mechanism. For example: > > (p1 | p2) & p3 > > can be solved by: > > pattern "p1 | p2"; > pattern "p3"; +1 (obviously:-) > p1 | (p2 & p3) is trickier. Well, you can do it with a union: type union { type string { pattern p1; } type string { pattern p2; pattern p3; } } More readable than the suggested solution IMHO. > So I am not sure the additional complexity is worth it. +1. In general, it may have been mentioned on the list, but don't we have more restrictions than "must not break 1.0 modules" for 1.1? Something like "only include changes that are necessary to solve problems encountered in actual usage experience, not those that are only nice-to-haves". The amount of effort required for implementors to add a lot of new but not-really-necessary features should not be ignored I think, since it could have a negative impact on the acceptance of YANG in general. --Per From nobody Fri Apr 4 02:20:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241D01A02DA for ; Fri, 4 Apr 2014 02:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZL_IM6gBTsc for ; Fri, 4 Apr 2014 02:20:27 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC11A0213 for ; Fri, 4 Apr 2014 02:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A54DE540659 for ; Fri, 4 Apr 2014 11:20:21 +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 FDcyh1k4WrFj for ; Fri, 4 Apr 2014 11:20:11 +0200 (CEST) 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 0087E54013B for ; Fri, 4 Apr 2014 11:20:10 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 04 Apr 2014 11:20:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nUHtaDXU69xTSbCap9jYaDx39sk Subject: [netmod] new issue: add 'attribute' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:20:32 -0000 * add 'attribute' statement ** Description There is a need for using metadata or tags on YANG-modelled instances. A new YANG statement, 'attribute', is proposed to allow defining such attributes. It would be allowed only at the top level of a module so that it could be used for defining global attributes that can be attached to any data node. The statement would serve the following purposes: 1. Define semantics of the attribute by means of a 'description' statement. 2. Define a namespace and prefix for the attribute through the standard YANG mechanisms. 3. Allow the NETCONF/RESTCONF server to advertise support for particular sets of attributes via standard capabilities. An attribute defined through this statement would be mapped to a namespaced XML attribute. The 'attribute' statement can have 'if-feature' as its substatement. A typical use: attribute inactive { description "Disable a data node together with its subtree. The effect must be the same as if the data node was commented out." } -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 4 02:26:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1941A0364 for ; Fri, 4 Apr 2014 02:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOqHnOqLOR-G for ; Fri, 4 Apr 2014 02:26:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 423F71A001D for ; Fri, 4 Apr 2014 02:26:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3E549FD2; Fri, 4 Apr 2014 11:26:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SLhtP9o4tiKb; Fri, 4 Apr 2014 11:26:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 4 Apr 2014 11:26:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF7F82002F; Fri, 4 Apr 2014 11:26:32 +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 m5Q1aym4_t9t; Fri, 4 Apr 2014 11:26:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 888C92002C; Fri, 4 Apr 2014 11:26:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9F0AC2C24946; Fri, 4 Apr 2014 11:26:30 +0200 (CEST) Date: Fri, 4 Apr 2014 11:26:30 +0200 From: Juergen Schoenwaelder To: Per Hedeland Message-ID: <20140404092630.GB81055@elstar.local> Mail-Followup-To: Per Hedeland , Martin Bjorklund , netmod@ietf.org References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533E77D3.4030005@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Fo1XhPjnCdo37znFvfw0EoMtrlY Cc: netmod@ietf.org Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 09:26:42 -0000 On Fri, Apr 04, 2014 at 11:13:55AM +0200, Per Hedeland wrote: > +1. In general, it may have been mentioned on the list, but don't we > have more restrictions than "must not break 1.0 modules" for 1.1? > Something like "only include changes that are necessary to solve > problems encountered in actual usage experience, not those that are only > nice-to-haves". The amount of effort required for implementors to add a > lot of new but not-really-necessary features should not be ignored I > think, since it could have a negative impact on the acceptance of YANG > in general. The process is that the WG needs to reach concensus for each submitted issue whether it is appropriate to address it (this is when an issue moves from NEW to OPEN). I trust WG members that they will take into account the cost / benefit tradeoffs in their judgements. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Apr 4 02:48:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363771A0473 for ; Fri, 4 Apr 2014 02:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CxNn50biLCZ for ; Fri, 4 Apr 2014 02:48:12 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD31A012B for ; Fri, 4 Apr 2014 02:48:12 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id x13so3276180qcv.29 for ; Fri, 04 Apr 2014 02:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1Z88NL43uthUuG3t/TDh5YwKoBhEfODQEFkstt0c2Kc=; b=gOTgOGHBduSuyko70YWZfsULbC/g9OR8xenNYToetYryHwCQc9jPhuhKtOTl/cgkNr GcJgpSJCZyCM4DVrSp6OtDuipVIuH6l74uB5mK1B1/j9oLKtf6nw3uQGEKcZPt16HC9o js5+0trx3VjUVNRuw+ZGyU9AW+amWN6uQY8ILIcsh82PGvOmZsSeYFtqI1F3VGC4oUTE fYnqh6ffAVSmJZBxIcekN1O2u7kcfK5M0Jifc+Y5APVVayNXVpcCNrkwHsD6BsEw820S Sig1QC00oRR2OwArScY0eOopZ4Hny9N5B/UqmTgYkgTeeWVNi6AgWxQfQgHwzHxdO+af svxg== MIME-Version: 1.0 X-Received: by 10.140.49.233 with SMTP id q96mr12550182qga.76.1396604888151; Fri, 04 Apr 2014 02:48:08 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Fri, 4 Apr 2014 02:48:08 -0700 (PDT) Date: Fri, 4 Apr 2014 17:48:08 +0800 Message-ID: From: chong feng To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11351ce23ffaed04f6346a42 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0J7IKAyjy7bECTHqEabes8p088I Subject: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:48:18 -0000 --001a11351ce23ffaed04f6346a42 Content-Type: text/plain; charset=ISO-8859-1 anyxml statement is assumed the data based yang model will be represent with XML. But in restconf, it can be represent with json. So anyxml can not express this situation. I suggest remove anyxml statement,instead of anydata statement. And add format substatement to express format,such as xml,json,etc. xml is default. for example: anydata data { format json. } --001a11351ce23ffaed04f6346a42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    anyxml statement is assumed the data based yang model will= be represent with XML. But in restconf, it can be represent with json. So = anyxml can not express this situation.

    I suggest remove = anyxml statement,instead of anydata statement. And add format substatement = to=A0
    express format,such as xml,json,etc. xml is default.

    for example:

    anydata data {
    =A0 = =A0 format json.
    }
    --001a11351ce23ffaed04f6346a42-- From nobody Fri Apr 4 02:53:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8752E1A012B for ; Fri, 4 Apr 2014 02:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReBQ5sMz-3XB for ; Fri, 4 Apr 2014 02:53:06 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 43CBE1A004D for ; Fri, 4 Apr 2014 02:53:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2F6EA540659; Fri, 4 Apr 2014 11:53:01 +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 Pc3jqVzhNAnp; Fri, 4 Apr 2014 11:52:56 +0200 (CEST) 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 09A8C54013B; Fri, 4 Apr 2014 11:52:55 +0200 (CEST) From: Ladislav Lhotka To: Per Hedeland , Martin Bjorklund In-Reply-To: <533E77D3.4030005@tail-f.com> References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 04 Apr 2014 11:52:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Kaam672mXUkOiYNe0vhNrMQ-jjQ Cc: netmod@ietf.org Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:53:10 -0000 Per Hedeland writes: > On 2014-04-04 10:36, Martin Bjorklund wrote: >> Hi, >> >> My first reaction to this proposal is that it seems a bit >> complex. I can see the theoretical problem, but I have never seen >> this in a real module. In most cases, this can be solved with the >> current mechanism. For example: >> >> (p1 | p2) & p3 >> >> can be solved by: >> >> pattern "p1 | p2"; >> pattern "p3"; > > +1 (obviously:-) > >> p1 | (p2 & p3) is trickier. > > Well, you can do it with a union: > > type union { > type string { > pattern p1; > } > type string { > pattern p2; > pattern p3; > } > } Or also simply as (p1 | p2) & (p1 | p3). It might be helpful though to be able to define pattern variables because quite often the same fragments have to be repeated. Consider this alternative definition of IPv4 address type: typedef ipv4-address-no-zone { type string { let octet { pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; } pattern '($(octet)\.){3}$(octet)' } This would be IMO a very useful aid for readers. Lada > > More readable than the suggested solution IMHO. > >> So I am not sure the additional complexity is worth it. > > +1. In general, it may have been mentioned on the list, but don't we > have more restrictions than "must not break 1.0 modules" for 1.1? > Something like "only include changes that are necessary to solve > problems encountered in actual usage experience, not those that are only > nice-to-haves". The amount of effort required for implementors to add a > lot of new but not-really-necessary features should not be ignored I > think, since it could have a negative impact on the acceptance of YANG > in general. > > --Per > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 4 02:53:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8111A0122 for ; Fri, 4 Apr 2014 02:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX5oi1Epf476 for ; Fri, 4 Apr 2014 02:53:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A31A004D for ; Fri, 4 Apr 2014 02:53:37 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E32F3B4158; Fri, 4 Apr 2014 11:53:32 +0200 (CEST) Date: Fri, 04 Apr 2014 11:53:31 +0200 (CEST) Message-Id: <20140404.115331.117312144.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/d0qaANwgkTzA1ajhjbSOIvTVysg Cc: netmod@ietf.org Subject: Re: [netmod] new issue: add 'attribute' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:53:42 -0000 Hi, Added as Y33. /martin Ladislav Lhotka wrote: > * add 'attribute' statement > > ** Description > > There is a need for using metadata or tags on YANG-modelled instances. > > A new YANG statement, 'attribute', is proposed to allow defining such > attributes. It would be allowed only at the top level of a module so > that it could be used for defining global attributes that can be > attached to any data node. > > The statement would serve the following purposes: > > 1. Define semantics of the attribute by means of a 'description' > statement. > 2. Define a namespace and prefix for the attribute through the standard > YANG mechanisms. > 3. Allow the NETCONF/RESTCONF server to advertise support for > particular sets of attributes via standard capabilities. > > An attribute defined through this statement would be mapped to a namespaced XML > attribute. > > The 'attribute' statement can have 'if-feature' as its substatement. > > A typical use: > > attribute inactive { > description > "Disable a data node together with its subtree. > The effect must be the same as if the data node was > commented out." > } > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Apr 4 03:07:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA281A0139 for ; Fri, 4 Apr 2014 03:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmsUjE9mQGpb for ; Fri, 4 Apr 2014 03:07:19 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 22A7B1A018C for ; Fri, 4 Apr 2014 03:07:19 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id w7so3187629qcr.22 for ; Fri, 04 Apr 2014 03:07:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mxT9lj5/23AoSL/vEA+ZT86IbgXHvKsd9H6Xulh4v0w=; b=kYsG9obRN2oroUTf+seGspnHJe3wNfiNRbmz2qn7su+zTpgwP+GH+P6GTpeyUC3jGi wga8ZDVmJ78rSQHpQ3yEfMg5lo109nb3C19Us8kKc7p49iUAJIB+iha5Y9Rf99I8IPed fchn1XIOwwY3tqpev6bvw+rzJpDIyWupXHXLFbvI//UTm5VDnyhfe3B7YpTbAMqkyuuW pHSR6gaYqjeAGXZf9tESbheP5TTzmIDVEEF7XnofQlZ6S6GVLqoQ7QbUR5AmR/GoDG9+ 95nGAgNihwf03R0BWMWw0V/UYaeB8A9MBLc/vN65SJov5ihXNZH9643CnfqavwX18Qky iAvg== X-Gm-Message-State: ALoCoQlSGKPCor10L4CGOpBf9wIg3DiRwdkKoqUOxLLFUbFIHVOtqJlUbiuM+JPNck1LET74yTce MIME-Version: 1.0 X-Received: by 10.224.112.6 with SMTP id u6mr13141805qap.78.1396606034435; Fri, 04 Apr 2014 03:07:14 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 4 Apr 2014 03:07:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 03:07:14 -0700 Message-ID: From: Andy Bierman To: chong feng Content-Type: multipart/alternative; boundary=001a11c2e84892f39c04f634ae29 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/r3Vfl2BOW4bWQcs_EWQHzUSMt-8 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 10:07:23 -0000 --001a11c2e84892f39c04f634ae29 Content-Type: text/plain; charset=ISO-8859-1 Hi, I do not understand this issue. The anyxml statement works in RESTCONF and works in JSON. Andy On Fri, Apr 4, 2014 at 2:48 AM, chong feng wrote: > anyxml statement is assumed the data based yang model will be represent > with XML. But in restconf, it can be represent with json. So anyxml can not > express this situation. > > I suggest remove anyxml statement,instead of anydata statement. And add > format substatement to > express format,such as xml,json,etc. xml is default. > > for example: > > anydata data { > format json. > } > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11c2e84892f39c04f634ae29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I do not understand this issue.
    The anyxml statement works in RESTCONF and works in JSON.
    =

    Andy



    On Fri, Apr 4, 2014 at 2:48 AM, chong fe= ng <fengchongllly@gmail.com> wrote:
    anyxml statement is assumed the data based yang model will= be represent with XML. But in restconf, it can be represent with json. So = anyxml can not express this situation.

    I suggest remove = anyxml statement,instead of anydata statement. And add format substatement = to=A0
    express format,such as xml,json,etc. xml is default.

    for example:

    anydata data {
    =A0 = =A0 format json.
    }

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod


    --001a11c2e84892f39c04f634ae29-- From nobody Fri Apr 4 03:12:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAED1A00DB for ; Fri, 4 Apr 2014 03:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49m93bPFKbKL for ; Fri, 4 Apr 2014 03:12:07 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 07E8E1A0048 for ; Fri, 4 Apr 2014 03:12:06 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so2854388qaj.21 for ; Fri, 04 Apr 2014 03:12:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mqlS0Yed+jsAlETjI8aMr5BAMliUs0sqemzqU50pJug=; b=U2HxDHzgafFWdlzcXNtFlp6CocYFWpx14PqO0QKz0e9V05oejqMwJXhIxx3JMgSxx2 dczFBL0zQ8gY5WE06w6mP+xpQQR06KO8Evxd/CGG68Z9rG1JGDK4n62UrtHEBjHYB6ol zEvWvdD9NxkwTey3mWCU65Luj7xNSvdny4xMOY6LyViDGFev/T3Yt/++nAEL6mBWOtTR 0l1pvROD9F/kjcewfN4ke84DQgrEYPTJRkAKpL66boUN3Z+h9QIYZ0pVI1E/hEowO51w Pj5P7UUlgdXFQLXzAwm0vqYrMT9K3AeGhMnzYHGuMn43kbXUiSWGlrAEXzNqMPwYh5Q8 G38g== X-Gm-Message-State: ALoCoQnpLZ+8UpLLILvJyIKo+cRJvCGyhWPxHPIpKWXDE0ehtceiW4gCdxqsQX79grG+6MLr8BZE MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr13202319qaa.7.1396606322207; Fri, 04 Apr 2014 03:12:02 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 4 Apr 2014 03:12:02 -0700 (PDT) In-Reply-To: References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> Date: Fri, 4 Apr 2014 03:12:02 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bea3986ba00a604f634bf35 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/becu4A8UoYYTNk9Pq-wECSvV-Fc Cc: "netmod@ietf.org" Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 10:12:11 -0000 --047d7bea3986ba00a604f634bf35 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 4, 2014 at 2:52 AM, Ladislav Lhotka wrote: > Per Hedeland writes: > > > On 2014-04-04 10:36, Martin Bjorklund wrote: > >> Hi, > >> > >> My first reaction to this proposal is that it seems a bit > >> complex. I can see the theoretical problem, but I have never seen > >> this in a real module. In most cases, this can be solved with the > >> current mechanism. For example: > >> > >> (p1 | p2) & p3 > >> > >> can be solved by: > >> > >> pattern "p1 | p2"; > >> pattern "p3"; > > > > +1 (obviously:-) > > > >> p1 | (p2 & p3) is trickier. > > > > Well, you can do it with a union: > > > > type union { > > type string { > > pattern p1; > > } > > type string { > > pattern p2; > > pattern p3; > > } > > } > > Or also simply as (p1 | p2) & (p1 | p3). > > It might be helpful though to be able to define pattern variables because > quite often the same fragments have to be repeated. Consider this > alternative definition of IPv4 address type: > > typedef ipv4-address-no-zone { > type string { > let octet { > pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; > } > pattern '($(octet)\.){3}$(octet)' > } > > This would be IMO a very useful aid for readers. > > IMO we have plenty of esoteric syntax already. The pattern-stmt does not need expandable variables. The description-stmt should explain the intent, so the pattern does not need to be that human-readable. Lada > Andy > > > > > More readable than the suggested solution IMHO. > > > >> So I am not sure the additional complexity is worth it. > > > > +1. In general, it may have been mentioned on the list, but don't we > > have more restrictions than "must not break 1.0 modules" for 1.1? > > Something like "only include changes that are necessary to solve > > problems encountered in actual usage experience, not those that are only > > nice-to-haves". The amount of effort required for implementors to add a > > lot of new but not-really-necessary features should not be ignored I > > think, since it could have a negative impact on the acceptance of YANG > > in general. > > > > --Per > > > > _______________________________________________ > > 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 > --047d7bea3986ba00a604f634bf35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Fri, Apr 4, 2014 at 2:52 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:
    Per Hedeland <per@tail-f.com> writes:

    > On 2014-04-04 10:36, Martin Bjorklund wrote:
    >> Hi,
    >>
    >> My first reaction to this proposal is that it seems a bit
    >> complex. =A0I can see the theoretical problem, but I have never se= en
    >> this in a real module. =A0In most cases, this can be solved with t= he
    >> current mechanism. =A0For example:
    >>
    >> =A0 =A0(p1 | p2) & p3
    >>
    >> can be solved by:
    >>
    >> =A0 pattern "p1 | p2";
    >> =A0 pattern "p3";
    >
    > +1 (obviously:-)
    >
    >> =A0 p1 | (p2 & p3) is trickier.
    >
    > Well, you can do it with a union:
    >
    > =A0 =A0type union {
    > =A0 =A0 =A0type string {
    > =A0 =A0 =A0 =A0pattern p1;
    > =A0 =A0 =A0}
    > =A0 =A0 =A0type string {
    > =A0 =A0 =A0 =A0pattern p2;
    > =A0 =A0 =A0 =A0pattern p3;
    > =A0 =A0 =A0}
    > =A0 =A0}

    Or also simply as (p1 | p2) & (p1 | p3).

    It might be helpful though to be able to define pattern variables because q= uite often the same fragments have to be repeated. Consider this alternativ= e definition of IPv4 address type:

    typedef ipv4-address-no-zone {
    =A0 type string {
    =A0 =A0 let octet {
    =A0 =A0 =A0 pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]= )';
    =A0 =A0 }
    =A0 =A0 pattern '($(octet)\.){3}$(octet)'
    =A0 }

    This would be IMO a very useful aid for readers.



    IMO we have plenty of e= soteric syntax already.
    The pattern-stmt does not need expandable= variables.
    The description-stmt should explain the intent, so
    the pattern does not need to be that human-readable.


    Lada

    Andy
    =A0

    >
    > More readable than the suggested solution IMHO.
    >
    >> So I am not sure the additional complexity is worth it.
    >
    > +1. In general, it may have been mentioned on the list, but don't = we
    > have more restrictions than "must not break 1.0 modules" for= 1.1?
    > Something like "only include changes that are necessary to solve<= br> > problems encountered in actual usage experience, not those that are on= ly
    > nice-to-haves". The amount of effort required for implementors to= add a
    > lot of new but not-really-necessary features should not be ignored I > think, since it could have a negative impact on the acceptance of YANG=
    > in general.
    >
    > --Per
    >
    > _______________________________________________
    > 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

    --047d7bea3986ba00a604f634bf35-- From nobody Fri Apr 4 04:23:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E51A00E6 for ; Fri, 4 Apr 2014 04:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmrsODfuJ5DS for ; Fri, 4 Apr 2014 04:23:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E4FA91A0134 for ; Fri, 4 Apr 2014 04:23:41 -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 5B3D53940B0; Fri, 4 Apr 2014 13:23:36 +0200 (CEST) Message-ID: <533E9637.5090301@tail-f.com> Date: Fri, 04 Apr 2014 13:23:35 +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: Ladislav Lhotka References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4w1we1-UN3aH69DZSHGvp1fxr5k Cc: netmod@ietf.org Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:23:47 -0000 On 2014-04-04 11:52, Ladislav Lhotka wrote: > Per Hedeland writes: > >> On 2014-04-04 10:36, Martin Bjorklund wrote: >> >>> p1 | (p2 & p3) is trickier. >> >> Well, you can do it with a union: >> >> type union { >> type string { >> pattern p1; >> } >> type string { >> pattern p2; >> pattern p3; >> } >> } > > Or also simply as (p1 | p2) & (p1 | p3). You're changing the requirements, that's cheating.:-) And besides being more cumbersome to write and read (prompting your other suggestion), it may also have a significant impact on the performance of verification. --Per From nobody Fri Apr 4 04:32:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D241A0139 for ; Fri, 4 Apr 2014 04:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgD1_AifhYK0 for ; Fri, 4 Apr 2014 04:32:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F2A931A0133 for ; Fri, 4 Apr 2014 04:32:08 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4595E140139; Fri, 4 Apr 2014 13:32:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396611123; bh=yah20A8w/ZX4tEK5Ya/8LzGE6F9iGQjLJqa5bCImPTk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ksj7ce0yVzL5FGT5RsZX6XvFXEfB39IFPtwWTCxWvlp5xWySC/4Ld6nlAHiCEyhe1 rRi0rMYaqQc+fl9TyF1dXQzCpACCKChHdl0yXndKHT2weRy4v2Oyxp/5fikFCC/XT6 U1lvmkLcvH4Eae8DORfhw7Db/LXPqVvVODbOxDXw= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <533E9637.5090301@tail-f.com> Date: Fri, 4 Apr 2014 13:32:02 +0200 Content-Transfer-Encoding: 7bit Message-Id: <53A0265E-3A93-4D1B-A8F1-F4D8D6E6E379@nic.cz> References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> <533E9637.5090301@tail-f.com> To: Per Hedeland X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/68gfQLJ7lQTNdF62aFJ-gUZbplA Cc: netmod@ietf.org Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:32:13 -0000 On 04 Apr 2014, at 13:23, Per Hedeland wrote: > On 2014-04-04 11:52, Ladislav Lhotka wrote: >> Per Hedeland writes: >> >>> On 2014-04-04 10:36, Martin Bjorklund wrote: >>> >>>> p1 | (p2 & p3) is trickier. >>> >>> Well, you can do it with a union: >>> >>> type union { >>> type string { >>> pattern p1; >>> } >>> type string { >>> pattern p2; >>> pattern p3; >>> } >>> } >> >> Or also simply as (p1 | p2) & (p1 | p3). > > You're changing the requirements, that's cheating.:-) And besides being How do I change anything? It is possible even now: pattern "p1|p2"; pattern "p1|p3"; (of yourse, p1 has to by literally copied). Lada > more cumbersome to write and read (prompting your other suggestion), it > may also have a significant impact on the performance of verification. > > --Per -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 4 04:35:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F521A0133 for ; Fri, 4 Apr 2014 04:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhScAvkTUuUz for ; Fri, 4 Apr 2014 04:35:32 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by ietfa.amsl.com (Postfix) with ESMTP id AC1FE1A0136 for ; Fri, 4 Apr 2014 04:35:32 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id f51so3164492qge.16 for ; Fri, 04 Apr 2014 04:35:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5TGde2yi72jofFCADMIwmsjF3LpL+hdMBMWeUrJ2lmg=; b=EOVG9wNQ/wR9oA+EZ8FdmOIT9mTs8ocBnI6QB/IfDFEGbp6229otrOJRZi6fy4Y6Ob BkHGYMslMrGkONAi1XwsblzNz1Wts2GVaOlTrtcJ9zDpJe0sIj8oITFRfhZ1nCWkdyHJ gAoWCK5iXwDxQO1Odvqk6D1LjqVWTaVKEiqrv8c7NTm03wF/lFwlS/jATytYlhirz6Y+ Q9Dt/n2ZQ24tHOKw8fBbVySZZzIWSGtOdOgNWNFINUme34fFLa3cZdPnHR2csPNiZFqC LM9aezAyolX6blGpvQHR7X1x8r8BYEpabpNxSq1R4Arys6rhEiMBrBIDLuZ3kD2G+gBI 0Qew== X-Gm-Message-State: ALoCoQnAALklvX95FKKWVwFtq5yGOlRS8zKNp2OjGCZdvxIztLLcAOo5bZUCeZVUT+muZEqW9SBs MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr12891873qge.34.1396611327910; Fri, 04 Apr 2014 04:35:27 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 4 Apr 2014 04:35:27 -0700 (PDT) In-Reply-To: <533E9637.5090301@tail-f.com> References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> <533E9637.5090301@tail-f.com> Date: Fri, 4 Apr 2014 04:35:27 -0700 Message-ID: From: Andy Bierman To: Per Hedeland Content-Type: multipart/alternative; boundary=001a1139a9701710d504f635eae6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JhFBenu6NBt5AbXZQxi_7MNv20M Cc: "netmod@ietf.org" Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:35:37 -0000 --001a1139a9701710d504f635eae6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 4, 2014 at 4:23 AM, Per Hedeland wrote: > On 2014-04-04 11:52, Ladislav Lhotka wrote: > > Per Hedeland writes: > > > >> On 2014-04-04 10:36, Martin Bjorklund wrote: > >> > >>> p1 | (p2 & p3) is trickier. > >> > >> Well, you can do it with a union: > >> > >> type union { > >> type string { > >> pattern p1; > >> } > >> type string { > >> pattern p2; > >> pattern p3; > >> } > >> } > > > IMO this union type is more readable. > Or also simply as (p1 | p2) & (p1 | p3). > > You're changing the requirements, that's cheating.:-) And besides being > more cumbersome to write and read (prompting your other suggestion), it > may also have a significant impact on the performance of verification. > > We have to make sure that YANG 1.0 modules still compile, so any proposal that doesn't do that should be immediately rejected. If there are already ways in YANG to solve the problem, then there should be strong consensus that the current mechanisms are too hard to use, or else reject the proposal. > --Per > Andy --001a1139a9701710d504f635eae6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Fri, Apr 4, 2014 at 4:23 AM, Per Hedeland <= per@tail-f.com><= /span> wrote:
    On 2014-04-04 11:52, Ladislav Lhotka wrote:<= br> > Per Hedeland <per@tail-f.com&= gt; writes:
    >
    >> On 2014-04-04 10:36, Martin Bjorklund wrote:
    >>
    >>> =A0 p1 | (p2 & p3) is trickier.
    >>
    >> Well, you can do it with a union:
    >>
    >> =A0 =A0type union {
    >> =A0 =A0 =A0type string {
    >> =A0 =A0 =A0 =A0pattern p1;
    >> =A0 =A0 =A0}
    >> =A0 =A0 =A0type string {
    >> =A0 =A0 =A0 =A0pattern p2;
    >> =A0 =A0 =A0 =A0pattern p3;
    >> =A0 =A0 =A0}
    >> =A0 =A0}
    >

    IMO this union type is more readab= le.

    > Or also simply as (p1 | p2) & (p1 | p3).

    You're changing the requirements, that's cheating.:-) And besides b= eing
    more cumbersome to write and read (prompting your other suggestion), it
    may also have a significant impact on the performance of verification.


    We have to make sure that YANG 1.0 mod= ules still compile, so any
    proposal that doesn't do that shou= ld be immediately rejected.

    If there are already w= ays in YANG to solve the problem, then there
    should be strong consensus that the current mechanisms are too hard
    to use, or else reject the proposal.

    =A0
    --Per

    Andy

    --001a1139a9701710d504f635eae6-- From nobody Fri Apr 4 04:35:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FF11A013A for ; Fri, 4 Apr 2014 04:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.539 X-Spam-Level: X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7Z9Kp1_Rsyb for ; Fri, 4 Apr 2014 04:35:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CDF501A0133 for ; Fri, 4 Apr 2014 04:35:46 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C5181140266; Fri, 4 Apr 2014 13:35:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396611341; bh=WpsEwjQdGCZD9XY1LItVBwesMFLq3UPuSAwzM5+I1+Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XiVU0eJUsOkO5ibOz+6BQWYYf09juT2Cn32nChlAEo8pPPupwWbsFv0NfKcatJA9p TxZKxFZVLneHZT9AutXXWvYeeGHetZtWFAdaoiMhMN39b/bsu2xfBUa924BeRt2QPs ABiiRhI/fuGQq+/tzzVHZn1GbNNp1MZi2aDemRuU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 4 Apr 2014 13:35:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7BBD1275-8844-4F1F-913A-1A9E9CA7F748@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BchIc59KNo8iuHmDhK-NGxAcw7I Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:35:54 -0000 On 04 Apr 2014, at 12:07, Andy Bierman wrote: > Hi, >=20 > I do not understand this issue. > The anyxml statement works in RESTCONF and works in JSON. The proposal, as I understand it, tries to replace =93anyxml=94 with a = more neutral name. I agree it is a bit weird that =93any XML=94 can also = mean =93any JSON". Lada >=20 >=20 > Andy >=20 >=20 >=20 > On Fri, Apr 4, 2014 at 2:48 AM, chong feng = wrote: > anyxml statement is assumed the data based yang model will be = represent with XML. But in restconf, it can be represent with json. So = anyxml can not express this situation. >=20 > I suggest remove anyxml statement,instead of anydata statement. And = add format substatement to=20 > express format,such as xml,json,etc. xml is default. >=20 > for example: >=20 > anydata data { > format json. > } >=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 nobody Fri Apr 4 04:47:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751961A0150 for ; Fri, 4 Apr 2014 04:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRZNEXUcde0A for ; Fri, 4 Apr 2014 04:47:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C89691A013F for ; Fri, 4 Apr 2014 04:47:03 -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 E87BB476C31; Fri, 4 Apr 2014 13:46:58 +0200 (CEST) Message-ID: <533E9BB2.8060306@tail-f.com> Date: Fri, 04 Apr 2014 13:46:58 +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: Ladislav Lhotka References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> <533E9637.5090301@tail-f.com> <53A0265E-3A93-4D1B-A8F1-F4D8D6E6E379@nic.cz> In-Reply-To: <53A0265E-3A93-4D1B-A8F1-F4D8D6E6E379@nic.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ljqkfG4P8jESt5CePBXJ_wKFb8g Cc: netmod@ietf.org Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:47:09 -0000 On 2014-04-04 13:32, Ladislav Lhotka wrote: > > On 04 Apr 2014, at 13:23, Per Hedeland wrote: > >> On 2014-04-04 11:52, Ladislav Lhotka wrote: >>> Per Hedeland writes: >>> >>>> On 2014-04-04 10:36, Martin Bjorklund wrote: >>>> >>>>> p1 | (p2 & p3) is trickier. >>>> >>>> Well, you can do it with a union: >>>> >>>> type union { >>>> type string { >>>> pattern p1; >>>> } >>>> type string { >>>> pattern p2; >>>> pattern p3; >>>> } >>>> } >>> >>> Or also simply as (p1 | p2) & (p1 | p3). >> >> You're changing the requirements, that's cheating.:-) And besides being > > How do I change anything? It is possible even now: Yes of course. The requirement was to express p1 | (p2 & p3), you're changing it to express (p1 | p2) & (p1 | p3) - obviously the semantics are the same, but it is not what was asked for. > pattern "p1|p2"; > pattern "p1|p3"; > > (of yourse, p1 has to by literally copied). Exactly. And the implementation (unless it employs some rather advanced - and probably unlikely to be implemented - optimization techniques) will need to do the match-check for p1 twice instead of once. --Per > Lada > >> more cumbersome to write and read (prompting your other suggestion), it >> may also have a significant impact on the performance of verification. >> >> --Per > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Apr 4 04:50:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7435B1A0155 for ; Fri, 4 Apr 2014 04:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bZlocXWwWGe for ; Fri, 4 Apr 2014 04:50:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63E1A0150 for ; Fri, 4 Apr 2014 04:50:23 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id C827E476C31; Fri, 4 Apr 2014 13:50:17 +0200 (CEST) Date: Fri, 04 Apr 2014 13:50:17 +0200 (CEST) Message-Id: <20140404.135017.215731469.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <7BBD1275-8844-4F1F-913A-1A9E9CA7F748@nic.cz> References: <7BBD1275-8844-4F1F-913A-1A9E9CA7F748@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HOiXDfIn5U2w84Q7AAG-s9Zo7Zs Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:50:27 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDA0IEFwciAy MDE0LCBhdCAxMjowNywgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0K PiANCj4gPiBIaSwNCj4gPiANCj4gPiBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoaXMgaXNzdWUuDQo+ ID4gVGhlIGFueXhtbCBzdGF0ZW1lbnQgd29ya3MgaW4gUkVTVENPTkYgYW5kIHdvcmtzIGluIEpT T04uDQo+IA0KPiBUaGUgcHJvcG9zYWwsIGFzIEkgdW5kZXJzdGFuZCBpdCwgdHJpZXMgdG8gcmVw bGFjZSDigJxhbnl4bWzigJ0gd2l0aCBhIG1vcmUgbmV1dHJhbA0KPiBuYW1lLg0KDQpUaGUgcHJv cG9zYWwgYWxzbyBhZGRzIGEgZm9ybWF0IHBhcmFtZXRlci4gIEkgdGhpbmsgdGhhdCBzaG91bGQg YmUNCmF2b2lkZWQ7IHNpbmNlIGl0IG1lYW5zIHlvdSBoYXZlIHRvIGtub3cgdGhlIGZvcm1hdCB3 aGVuIHlvdSB3cml0ZSB0aGUNCmRhdGEgbW9kZWwgKG5vdyB3ZSdyZSBnZXR0aW5nIGludG8gdGhl IHByb2JsZW1zIG9mIHRyeWluZyB0byBoYXZlIGENCnByb3RvY29sIG5ldXRyYWwgbW9kZWxsaW5n IGxhbmd1YWdlLi4uKQ0KDQo+IEkgYWdyZWUgaXQgaXMgYSBiaXQgd2VpcmQgdGhhdCDigJxhbnkg WE1M4oCdIGNhbiBhbHNvIG1lYW4g4oCcYW55IEpTT04iLg0KDQorMQ0KDQpXZSBjb3VsZCBrZWVw ICdhbnl4bWwnIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgYW5kIGFkZCAnYW55ZGF0YScN Cih3aXRoIG5vICdmb3JtYXQnKS4NCg0KQnV0IEkgd29uZGVyIGlmIGl0IHdvcmtzLi4uIGFueXht bCBwdXRzIG5vIHJlc3RyaWN0aW9ucyBvbiB0aGUgeG1sLCBzbw0KaXQgY2Fubm90IGluIGdlbmVy YWwgYmUgdHJhbnNsYXRlZCB0byBKU09OLiAgTWF5YmUgd2UgY291bGQga2VlcA0KYW55eG1sIGFz IGlzLCBhbmQgYWxzbyBhZGQgYW55ZGF0YS4gIFVuY2xlYXIgaWYgdGhpcyBzb2x2ZXMgYW55dGhp bmcNCnRob3VnaC4NCg0KDQovbWFydGluDQo= From nobody Fri Apr 4 04:53:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428CB1A016B for ; Fri, 4 Apr 2014 04:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIWFRpW4OwiO for ; Fri, 4 Apr 2014 04:53:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 59EFE1A0150 for ; Fri, 4 Apr 2014 04:53:03 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8375B14026A; Fri, 4 Apr 2014 13:52:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396612377; bh=a0UiT5dDIg4MVJA0FQqm4EDTi0BKYg5R03VA7j85DZ4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ufGTEY6p9g+lR/X85oDtw2CPKN7WNapkkb05dgiRDTmi5ahuTjU8FSq70bJtUjRE/ K/4pZPk92MH1pPpIWCnY8svmaD91tzmy6fNn5GNBCaXh4RkTu8LWJ4L5k5E+U2IOQi gv7CIGPm8dOrbfd/qFKkMVr9tZlWe7W8ZjSBqDQI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 4 Apr 2014 13:52:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33FCB700-E959-48FD-9CD8-0007AEC4001B@nic.cz> References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> <533E9637.5090301@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nQaM65NwSKb8G0EsjVlaWbR3HhU Cc: "netmod@ietf.org" Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:53:07 -0000 On 04 Apr 2014, at 13:35, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Apr 4, 2014 at 4:23 AM, Per Hedeland wrote: > On 2014-04-04 11:52, Ladislav Lhotka wrote: > > Per Hedeland writes: > > > >> On 2014-04-04 10:36, Martin Bjorklund wrote: > >> > >>> p1 | (p2 & p3) is trickier. > >> > >> Well, you can do it with a union: > >> > >> type union { > >> type string { > >> pattern p1; > >> } > >> type string { > >> pattern p2; > >> pattern p3; > >> } > >> } > > >=20 > IMO this union type is more readable. On the other hand, it can be difficult to determine which of the union = cases actually applies. >=20 > > Or also simply as (p1 | p2) & (p1 | p3). >=20 > You're changing the requirements, that's cheating.:-) And besides = being > more cumbersome to write and read (prompting your other suggestion), = it > may also have a significant impact on the performance of verification. >=20 >=20 > We have to make sure that YANG 1.0 modules still compile, so any > proposal that doesn't do that should be immediately rejected. OK, the =91patterns=92 container isn=92t needed, and without it this = requirement is satisfied.=20 >=20 > If there are already ways in YANG to solve the problem, then there > should be strong consensus that the current mechanisms are too hard > to use, or else reject the proposal. You often emphasize the sequence of priorities: module readers, then = module writers, and then software tools. It is the case here: with = pattern variables some awkward patterns would be much easier to = understand, and writers would be less likely to make a typo. Lada >=20 > =20 > --Per >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 4 05:01:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660521A0141 for ; Fri, 4 Apr 2014 05:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5Gn1eS_kaly for ; Fri, 4 Apr 2014 05:01:51 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3B51A0140 for ; Fri, 4 Apr 2014 05:01:51 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id o15so3037838qap.9 for ; Fri, 04 Apr 2014 05:01:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KNvA3YhRUv+n9FyOhNTOXgooZ8L5n39uUPBATsNcTvc=; b=VLYCYyxz3dDbVJcueUTr0/MRLnfZrnTd5xzsSBXQpoPIGPVimPzsmgZwXwyPjRw8Q0 IQUrU18jcbBfhXAyN0nX27KDeuEfg6eqMYyukHYrGeFRW5ayZqVEyjVMgRoIZokLOUs7 fFHDl/GUXUZO9dbtXryelhaj+jmLySKYVC15SFwCm90zPooaW8Xq2j1wXBEjEQ6QRpZ8 XvlY63Sm0eu25WrKTFbCK3Rl2Qzpa2vaAmhxPAZ/FjZnoCD9fJBEQnIg3tvOD8WUP0zo ghz/CCmnuhFs2UVq+JlLkf917Ijgcdcz2MfNnCLL7TR7042cf9sjO0JxOFbKXTP/RZpS 7HIA== X-Gm-Message-State: ALoCoQlZ9d734q1QzHyv/uVFvIwF/kbYS0qt5yuKIUNPRiXp7J/ckE8gOXSfbSaYwsp23HWT7VVW MIME-Version: 1.0 X-Received: by 10.140.92.6 with SMTP id a6mr13024253qge.34.1396612905854; Fri, 04 Apr 2014 05:01:45 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 4 Apr 2014 05:01:45 -0700 (PDT) In-Reply-To: <20140404.135017.215731469.mbj@tail-f.com> References: <7BBD1275-8844-4F1F-913A-1A9E9CA7F748@nic.cz> <20140404.135017.215731469.mbj@tail-f.com> Date: Fri, 4 Apr 2014 05:01:45 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1139a97024717404f63648d8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MRmnO7F3E-0oezFrJcMAZ1Lbxko Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:01:55 -0000 --001a1139a97024717404f63648d8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 4, 2014 at 4:50 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 04 Apr 2014, at 12:07, Andy Bierman wrote: > > > > > Hi, > > > > > > I do not understand this issue. > > > The anyxml statement works in RESTCONF and works in JSON. > > > > The proposal, as I understand it, tries to replace "anyxml" with a more > neutral > > name. > > The proposal also adds a format parameter. I think that should be > avoided; since it means you have to know the format when you write the > data model (now we're getting into the problems of trying to have a > protocol neutral modelling language...) > > I don't understand the format-stmt at all. Only protocol messages have an encoding, and they are just representations. XML vs. JSON is not a property of the data model. > I agree it is a bit weird that "any XML" can also mean "any JSON". > > +1 > > We could keep 'anyxml' for backwards compatibility, and add 'anydata' > (with no 'format'). > > But I wonder if it works... anyxml puts no restrictions on the xml, so > it cannot in general be translated to JSON. Maybe we could keep > anyxml as is, and also add anydata. Unclear if this solves anything > though. > > This is not worth changing (although I argued for the name 'any' because that is what NCX implemented ;-) We would have to keep 'anyxml' and then keep explaining that there is no difference at all between 'anyxml' and 'anydata'. Any time there are multiple ways to do the same thing, it causes operators and developers to spend time figuring out exactly how they are different, and when to use each one. > > /martin > Andy --001a1139a97024717404f63648d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Fri, Apr 4, 2014 at 4:50 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
    Ladislav Lhotka <lhotka@nic.cz> wrote:
    >
    > On 04 Apr 2014, at 12:07, Andy Bierman <andy@yumaworks.com> wrote:
    >
    > > Hi,
    > >
    > > I do not understand this issue.
    > > The anyxml statement works in RESTCONF and works in JSON.
    >
    > The proposal, as I understand it, tries to replace “anyxml&rdquo= ; with a more neutral
    > name.

    The proposal also adds a format parameter.  I think that should be
    avoided; since it means you have to know the format when you write the
    data model (now we're getting into the problems of trying to have a
    protocol neutral modelling language...)


    I don't understand the format-stmt= at all.
    Only protocol messages have an encoding, and they are ju= st representations.
    XML vs. JSON is not a property of the data mo= del.


    > I agree it is a bit weird that “any XML” can also mean &ld= quo;any JSON".

    +1

    We could keep 'anyxml' for backwards compatibility, and add 'an= ydata'
    (with no 'format').

    But I wonder if it works... anyxml puts no restrictions on the xml, so
    it cannot in general be translated to JSON.  Maybe we could keep
    anyxml as is, and also add anydata.  Unclear if this solves anything though.


    This is not worth changing (although I argued for th= e name 'any'
    because that is what NCX implemented ;-)

    We would have to keep 'anyxml' and then keep ex= plaining that
    there is no difference at all between 'anyxml&#= 39; and 'anydata'.

    Any time there are mult= iple ways to do the same thing, it causes
    operators and developers to spend time figuring out exactly how they
    are different, and when to use each one.

    =  

    /martin

    Andy<= /div>

    --001a1139a97024717404f63648d8-- From nobody Fri Apr 4 05:06:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394B21A0141 for ; Fri, 4 Apr 2014 05:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_seo5bDsU1B for ; Fri, 4 Apr 2014 05:06: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 E7AE91A0140 for ; Fri, 4 Apr 2014 05:06:15 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6F174140139; Fri, 4 Apr 2014 14:06:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396613169; bh=NVQmHzkDMM/CB/7T7P/ATy6P/wxbcRbo9muvTsAZBaE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YsYvw8bSe63DxhCBmZE5Ko3plcJBCGWFJ5k7zd7HhfIYxjZLyPDsZGFYVNi8bfPRp HWyEpz/UX5DIMwYrnZ5K/n9KJo8CRpiOmRWEq/XTS0yx3pNeVkNvAqVrF5E21XvHqW /Qn3qSCNFmpc4NjeasDVNUSe46ZZJ+vj1W5IOXtQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <533E9BB2.8060306@tail-f.com> Date: Fri, 4 Apr 2014 14:06:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <941F8561-4D6A-4EA6-BA7B-972222D9E311@nic.cz> References: <20140404.103610.493044772.mbj@tail-f.com> <533E77D3.4030005@tail-f.com> <533E9637.5090301@tail-f.com> <53A0265E-3A93-4D1B-A8F1-F4D8D6E6E379@nic.cz> <533E9BB2.8060306@tail-f.com> To: Per Hedeland X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wTcSnBi4l7B2n1KVPsGKtjnVvlY Cc: netmod@ietf.org Subject: Re: [netmod] Y32: allow boolean combinations of patter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:06:20 -0000 On 04 Apr 2014, at 13:46, Per Hedeland wrote: > On 2014-04-04 13:32, Ladislav Lhotka wrote: >>=20 >> On 04 Apr 2014, at 13:23, Per Hedeland wrote: >>=20 >>> On 2014-04-04 11:52, Ladislav Lhotka wrote: >>>> Per Hedeland writes: >>>>=20 >>>>> On 2014-04-04 10:36, Martin Bjorklund wrote: >>>>>=20 >>>>>> p1 | (p2 & p3) is trickier. >>>>>=20 >>>>> Well, you can do it with a union: >>>>>=20 >>>>> type union { >>>>> type string { >>>>> pattern p1; >>>>> } >>>>> type string { >>>>> pattern p2; >>>>> pattern p3; >>>>> } >>>>> } >>>>=20 >>>> Or also simply as (p1 | p2) & (p1 | p3). >>>=20 >>> You're changing the requirements, that's cheating.:-) And besides = being >>=20 >> How do I change anything? It is possible even now: >=20 > Yes of course. The requirement was to express p1 | (p2 & p3), you're > changing it to express (p1 | p2) & (p1 | p3) - obviously the semantics > are the same, but it is not what was asked for. >=20 >> pattern "p1|p2"; >> pattern "p1|p3"; >>=20 >> (of yourse, p1 has to by literally copied). >=20 > Exactly. And the implementation (unless it employs some rather = advanced > - and probably unlikely to be implemented - optimization techniques) > will need to do the match-check for p1 twice instead of once. If the patterns were defined using variables so that it is clear that p1 = is the same in both patterns, then such an optimization wouldn=92t be = rocket science. And one could also optimize parsing of IP addresses = because then it is immediately clear that only one DFA is needed for = parsing =93octet=94. Lada >=20 > --Per >=20 >> Lada >>=20 >>> more cumbersome to write and read (prompting your other suggestion), = it >>> may also have a significant impact on the performance of = verification. >>>=20 >>> --Per >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 4 05:08:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E041A0144 for ; Fri, 4 Apr 2014 05:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWO1SMzFMV-c for ; Fri, 4 Apr 2014 05:08:19 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D82D91A0140 for ; Fri, 4 Apr 2014 05:08:18 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id CBEE13B4159; Fri, 4 Apr 2014 14:08:13 +0200 (CEST) Date: Fri, 04 Apr 2014 14:08:13 +0200 (CEST) Message-Id: <20140404.140813.120271777.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <7BBD1275-8844-4F1F-913A-1A9E9CA7F748@nic.cz> <20140404.135017.215731469.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Aya-jEk78B7DOMQ-Gtoqi-dyosg Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:08:23 -0000 Andy Bierman wrote: > This is not worth changing (although I argued for the name 'any' > because that is what NCX implemented ;-) I think you are right. > We would have to keep 'anyxml' and then keep explaining that > there is no difference at all between 'anyxml' and 'anydata'. anyxml is unrestricted xml (including mixed content etc), and always xml (should be xml also in the json mapping, imo). anyxml should be used only when the format is known to be xml, like current NETCONF edit-config. anydata would be an unknown chunk of data that can be modelled with YANG. can be encoded as xml or json. /martin From nobody Fri Apr 4 05:13:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38BD1A0150 for ; Fri, 4 Apr 2014 05:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxzoGm7QXyHt for ; Fri, 4 Apr 2014 05:13:34 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED121A0037 for ; Fri, 4 Apr 2014 05:13:34 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id w7so3288859qcr.8 for ; Fri, 04 Apr 2014 05:13:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zHJDXExatnB+hsl1Zi+yWjaBAdaqweGoLqVZRpv46Os=; b=QCtfVxC0COzodznuw+lrfnt1BsLhY/EnvcVk8pTiE4P78HfBsNtItkXbpap6dA0UAl 1PGngQMRMmhzQ7JbeBDZNZhRscTIS4k1EwQvOf3xyfdaaZiormse7jrA3FuOWjS5mw6J 8GvemWJkjt3TvjuTP5NMvhvvDMcqDQxgdST9B1XE4fX3652bS9eMpEbEoih4fsGt5pfr Plwvf8CA5sdke6ihO0aPW9EE4h5fz2/1r0jilkMErJ3Yag2ZYU0YaGYZAWSOne6YzMYR cMfNPwDMl2Gbx7QAHeXpSPQodXirE88yw4tQnAlV/ysxOgtKq7GClV0JF9YkDKX8uQk1 h8yQ== X-Gm-Message-State: ALoCoQmwzZT+VKRZF1VLuIul/s2dokFE6KP2AUbmMXVoDpQQWwKaKe0C6sY8HEPNf/wiV6WzClvK MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr13033002qgo.25.1396613609625; Fri, 04 Apr 2014 05:13:29 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 4 Apr 2014 05:13:29 -0700 (PDT) In-Reply-To: <20140404.140813.120271777.mbj@tail-f.com> References: <7BBD1275-8844-4F1F-913A-1A9E9CA7F748@nic.cz> <20140404.135017.215731469.mbj@tail-f.com> <20140404.140813.120271777.mbj@tail-f.com> Date: Fri, 4 Apr 2014 05:13:29 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c15fa6172b6104f63672f5 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1k-PjCLm2iufmTi-AmWCRhdDcBk Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:13:39 -0000 --001a11c15fa6172b6104f63672f5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 4, 2014 at 5:08 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > This is not worth changing (although I argued for the name 'any' > > because that is what NCX implemented ;-) > > I think you are right. > > > We would have to keep 'anyxml' and then keep explaining that > > there is no difference at all between 'anyxml' and 'anydata'. > > anyxml is unrestricted xml (including mixed content etc), and always > xml (should be xml also in the json mapping, imo). > anyxml should be used only when the format is known to be xml, like > current NETCONF edit-config. > > But we do not allow mixed mode XML in NETCONF messages so how would the ever contain that? What if I write a YANG module that I want to use with RESTCONF and/or NETCONF (that is, all of them :-) anydata would be an unknown chunk of data that can be modelled with > YANG. can be encoded as xml or json. > > Since we are adding your attribute encoding to Lada's JSON draft, there is no trouble encoding attributes and elements. That should be good enough. > > /martin > > Andy --001a11c15fa6172b6104f63672f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Fri, Apr 4, 2014 at 5:08 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
    Andy Bierman <andy@yumaworks.com> wrote:
    > This is not worth changing (although I argued for the name 'any= 9;
    > because that is what NCX implemented ;-)

    I think you are right.

    > We would have to keep 'anyxml' and then keep explaining that > there is no difference at all between 'anyxml' and 'anydat= a'.

    anyxml is unrestricted xml (including mixed content etc), and always
    =A0 xml (should be xml also in the json mapping, imo).
    =A0 anyxml should be used only when the format is known to be xml, like
    =A0 current NETCONF edit-config.


    But we do not allow mixed mode XML in = NETCONF messages so how would
    the <edit-config> ever contai= n that?

    What if I write a YANG module that I want = to use with RESTCONF and/or NETCONF
    (that is, all of them :-)


    anydata would be an unknown chunk of data that can be modelled with
    =A0 YANG. =A0can be encoded as xml or json.


    Since we are adding your attribute encoding to Lada&= #39;s JSON draft,
    there is no trouble encoding attributes and ele= ments. =A0That should be
    good enough.

    =A0

    /martin


    Andy<= /div>

    --001a11c15fa6172b6104f63672f5-- From nobody Fri Apr 4 05:43:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F39A1A015F for ; Fri, 4 Apr 2014 05:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBDRaUaK5fJQ for ; Fri, 4 Apr 2014 05:43:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 20CB11A0141 for ; Fri, 4 Apr 2014 05:43:36 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6127613F952; Fri, 4 Apr 2014 14:43:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396615403; bh=y7zTy/jx/Sz3UE2F9TXK+zt2oA9qUWyf00qKtvYc9BU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qH/vpyozxxC1Yy5MVeI5BW6vLS9+WS7/DSkZOmkO51wSTNBpcUgdUrMhGtnmGVBaQ uPedCfOHKHhx3ia+U/iDCeXHoogVuanMxttzt1VJvqXbjvIsYEHivzuRwMjIXzAbQI 4ePLKPYWpJSHNuYRV2H4DN5mvODXAzXUEgWwBZlU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140404.135017.215731469.mbj@tail-f.com> Date: Fri, 4 Apr 2014 14:43:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7BBD1275-8844-4F1F-913A-1A9E9CA7F748@nic.cz> <20140404.135017.215731469.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RCNBJRi65Wdr0nHN1haHAvYAgdY Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:43:40 -0000 On 04 Apr 2014, at 13:50, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 04 Apr 2014, at 12:07, Andy Bierman wrote: >>=20 >>> Hi, >>>=20 >>> I do not understand this issue. >>> The anyxml statement works in RESTCONF and works in JSON. >>=20 >> The proposal, as I understand it, tries to replace =93anyxml=94 with = a more neutral >> name. >=20 > The proposal also adds a format parameter. I think that should be > avoided; since it means you have to know the format when you write the > data model (now we're getting into the problems of trying to have a > protocol neutral modelling language=85) I suspect the proposal confuses the schema with instance, perhaps the = format parameter was intended to be used in an instance with a similar = role as media-type. Maybe it could be done using an attribute. >=20 >> I agree it is a bit weird that =93any XML=94 can also mean =93any = JSON". >=20 > +1 >=20 > We could keep 'anyxml' for backwards compatibility, and add 'anydata' > (with no 'format=92). +1 >=20 > But I wonder if it works... anyxml puts no restrictions on the xml, so > it cannot in general be translated to JSON. Maybe we could keep I think the question of whether some representation can be translated to = another is not important. With anydata foo; this should be OK: =93bar=94: { =85 } =20 Lada > anyxml as is, and also add anydata. Unclear if this solves anything > though. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 4 06:08:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4E1A0175 for ; Fri, 4 Apr 2014 06:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISDwjESXsslE for ; Fri, 4 Apr 2014 06:08:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 657DB1A015F for ; Fri, 4 Apr 2014 06:08:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A1674FA6; Fri, 4 Apr 2014 15:08:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 03sK2sKHvETe; Fri, 4 Apr 2014 15:08:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 4 Apr 2014 15:08:17 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 235BB2002F; Fri, 4 Apr 2014 15:08:17 +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 gUk5swhGmBQb; Fri, 4 Apr 2014 15:08:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F12A32002C; Fri, 4 Apr 2014 15:08:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 10FE82C252CC; Fri, 4 Apr 2014 15:08:15 +0200 (CEST) Date: Fri, 4 Apr 2014 15:08:15 +0200 From: Juergen Schoenwaelder To: chong feng Message-ID: <20140404130814.GA81688@elstar.local> Mail-Followup-To: chong feng , 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) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IHTjVUAXXQ2k3ntRQ6gqcGqFPCk Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 13:08:26 -0000 On Fri, Apr 04, 2014 at 05:48:08PM +0800, chong feng wrote: > anyxml statement is assumed the data based yang model will be represent > with XML. But in restconf, it can be represent with json. So anyxml can not > express this situation. > > I suggest remove anyxml statement,instead of anydata statement. And add > format substatement to > express format,such as xml,json,etc. xml is default. > > for example: > > anydata data { > format json. > } As technical contributor, I am fine with the subject line but not with the proposal. I think we should declare anyxml as deprecated and move on. Allowing arbitrary blobs of data and even making it an art by supporting different formats of arbitrary blobs of data does not lead to interoperability. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Apr 4 06:22:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7D1A017C for ; Fri, 4 Apr 2014 06:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imtI_mU-pBEZ for ; Fri, 4 Apr 2014 06:22:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 46A7B1A0174 for ; Fri, 4 Apr 2014 06:22:37 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id CD85C3940B0; Fri, 4 Apr 2014 15:22:31 +0200 (CEST) Date: Fri, 04 Apr 2014 15:22:31 +0200 (CEST) Message-Id: <20140404.152231.308141677.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140404130814.GA81688@elstar.local> References: <20140404130814.GA81688@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ppIjpVC_ZN2jcj1DiLIFwysA4-c Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 13:22:42 -0000 This is now Y34. Three proposed solutions are added. /martin From nobody Sat Apr 5 08:30:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD201A0470 for ; Sat, 5 Apr 2014 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kopll6zwKWrM for ; Sat, 5 Apr 2014 08:30:31 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C79351A01C4 for ; Sat, 5 Apr 2014 08:30:30 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so652851qgf.34 for ; Sat, 05 Apr 2014 08:30:25 -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=A4QoCvRgUizcl6lgXX0+jStJoOaGfmD29eNbn6cMRlM=; b=lNGDn6d/FbLbRLVRpPJpP/C4lJBWIXBozfWIPGkXsZTkALzX4PVfngCUBkMmMv5GZd ZdJcAeVAH5KKf22YrAAdnBEqJetsfQTfVmJzF6wdPdMqWtAcHY05t+KvLsX/7Mp3hfi7 kOaoX6PmvkpowjpDKPbEutpoLeoHZXGVymyCfIo2v7VDoDyadEtP/VWqcJw+boVI5v2i qbv3eVOYAzN9fJcd2AzHdO3UwScH9bcUqJms6XE+IHyy4++sJjkqjhKCEll98QbaDjWP fernmjvqMJ0apQx439Lm/rf4GB36+c0/EsnWj4iCnIXIV0Ss1mbYJLzsR9XZxyexVR2o fQ9Q== MIME-Version: 1.0 X-Received: by 10.224.152.17 with SMTP id e17mr1828164qaw.100.1396711825763; Sat, 05 Apr 2014 08:30:25 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Sat, 5 Apr 2014 08:30:25 -0700 (PDT) In-Reply-To: References: <20140404130814.GA81688@elstar.local> <20140404.152231.308141677.mbj@tail-f.com> Date: Sat, 5 Apr 2014 23:30:25 +0800 Message-ID: From: chong feng To: netmod@ietf.org Content-Type: multipart/alternative; boundary=089e0149d2e03a727304f64d50c9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/s9h8PaCcDDiY-jW40SYrouIQvSI Subject: [netmod] Fwd: YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 15:30:35 -0000 --089e0149d2e03a727304f64d50c9 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: chong feng Date: 2014-04-05 22:23 GMT+08:00 Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement To: Martin Bjorklund I agree 'remove format sub statement from anydata'. Anydata statement will be only used to define the data based on YANG schema. The encoding is decided by operation protocol ,such as NETCONF. BTW, I wonder whether adding a new substatment named 'path' to express the data must be based on determined path. For example: rpc get-interfaces-statistics { input { container interfaces { list interface { key ifname; leaf ifname { type string; } } } } output { anydata data { path if:interfaces-state/if:interface/if:statistics; } } } 2014-04-04 21:22 GMT+08:00 Martin Bjorklund : This is now Y34. > > Three proposed solutions are added. > > > /martin > --089e0149d2e03a727304f64d50c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    ---------- Forwarded me= ssage ----------
    From: chong feng <fengchongllly@= gmail.com>
    Date: 2014-04-05 22:23 GMT+08:00
    Subject: Re: [netmod] YANG1.1 issue: re= move anyxml statement
    To: Martin Bjorklund <mbj@tail-f.com>


    I agree 're= move format sub statement from anydata'. Anydata statement will be only= used to define the data based on YANG schema.
    The encoding is decided by operation protocol ,such as NETCONF.

    BTW, I wonder whether adding a new substatment named &#= 39;path' to express the data must be based on determined path.
    For example:
    rpc get-interfaces-statistics {

    =A0 =A0 =A0 input {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0container interfaces {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 list interface {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 key ifname;
    =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf ifname {
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 type string;
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 }
    = =A0 =A0 =A0 =A0 =A0 =A0 =A0}
    =A0 =A0 =A0 }
    =A0 =A0 =A0 output {
    =A0 =A0 =A0 =A0 =A0 =A0 anydata data {
    =A0 =A0 =A0 =A0 =A0 =A0 path if:interfaces-state/if:interface/if:statistics= ;
    =A0 =A0 = =A0 =A0 =A0 =A0 }
    =A0 =A0 =A0 }

    }


    = 2014-04-04 21:22 GMT+08:00 Martin Bjorklund <mbj@tail-f.com>:=

    This is now Y34.

    Three proposed solutions are added.


    /martin


    --089e0149d2e03a727304f64d50c9-- From nobody Sat Apr 5 08:38:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6A61A049A for ; Sat, 5 Apr 2014 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL6JoAHbQvTe for ; Sat, 5 Apr 2014 08:38:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id B119F1A0470 for ; Sat, 5 Apr 2014 08:38:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4295CF8E; Sat, 5 Apr 2014 17:37:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id r4PPLv7A--Mq; Sat, 5 Apr 2014 17:37:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 5 Apr 2014 17:37:57 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A57B42002F; Sat, 5 Apr 2014 17:37:57 +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 7zX1fhxtIICW; Sat, 5 Apr 2014 17:37:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 723FD2002C; Sat, 5 Apr 2014 17:37:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BDC472C27C11; Sat, 5 Apr 2014 17:37:54 +0200 (CEST) Date: Sat, 5 Apr 2014 17:37:54 +0200 From: Juergen Schoenwaelder To: chong feng Message-ID: <20140405153754.GA85829@elstar.local> Mail-Followup-To: chong feng , netmod@ietf.org References: <20140404130814.GA81688@elstar.local> <20140404.152231.308141677.mbj@tail-f.com> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lRovXEma99HefQF9IzcgZBW3dJg Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 05 Apr 2014 15:38:07 -0000 Why not simply use a with a filter? /js On Sat, Apr 05, 2014 at 11:30:25PM +0800, chong feng wrote: > ---------- Forwarded message ---------- > From: chong feng > Date: 2014-04-05 22:23 GMT+08:00 > Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement > To: Martin Bjorklund > > > I agree 'remove format sub statement from anydata'. Anydata statement will > be only used to define the data based on YANG schema. > The encoding is decided by operation protocol ,such as NETCONF. > > BTW, I wonder whether adding a new substatment named 'path' to express the > data must be based on determined path. > For example: > rpc get-interfaces-statistics { > > input { > container interfaces { > list interface { > key ifname; > leaf ifname { > type string; > } > } > } > } > output { > anydata data { > path if:interfaces-state/if:interface/if:statistics; > } > } > > } > > > 2014-04-04 21:22 GMT+08:00 Martin Bjorklund : > > This is now Y34. > > > > Three proposed solutions are added. > > > > > > /martin > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Apr 5 08:51:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26E1A04B8 for ; Sat, 5 Apr 2014 08:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il2Z9MDnn_8j for ; Sat, 5 Apr 2014 08:51:03 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B57D11A01BA for ; Sat, 5 Apr 2014 08:51:03 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id e89so213839qgf.5 for ; Sat, 05 Apr 2014 08:50:58 -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=tuJROEat9YJ/gHwOD4OGUFOFrgZZRAKvcPhKeZoE/ro=; b=Dza5JzumAOSIr0EKfjkn3nW1j6kkqE3BtfQjfHySlyXgl4AIQ3b5QGK0kJoNmQbsA1 K2/I5CuHpOJRJEOVAH/b3SsPRFvtQf/NNzlMr+bi/W+ixDalcyu0EJl4hudYCrj2Yhpm 0TTvD2uFrZrqdOjO7fZpcW5fkHPkqPhdffGrdfadwFgnPUHYs2zBH57FXp9RH1bEDNyk F+yBsv7rdqhkjbo6RzcllMDEklHGvETZsuITXemcgJl0X4yKHIov0qzOL3ew61it9RIT 3OiA6W8RXdl0KM+GkQQdkpcKjx1tCMTnhIVTobANv0nzH3hbXQdnS8+HcY1o3mH1G9KI l4tw== MIME-Version: 1.0 X-Received: by 10.224.57.142 with SMTP id c14mr22153913qah.23.1396713058572; Sat, 05 Apr 2014 08:50:58 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Sat, 5 Apr 2014 08:50:58 -0700 (PDT) In-Reply-To: <20140405153754.GA85829@elstar.local> References: <20140404130814.GA81688@elstar.local> <20140404.152231.308141677.mbj@tail-f.com> <20140405153754.GA85829@elstar.local> Date: Sat, 5 Apr 2014 23:50:58 +0800 Message-ID: From: chong feng To: Juergen Schoenwaelder , chong feng , netmod@ietf.org Content-Type: multipart/alternative; boundary=089e01536d4ab5b97f04f64d998b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LTfuJImBRLlEOd_uaGsgkbR6R4w Subject: Re: [netmod] Fwd: YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 15:51:07 -0000 --089e01536d4ab5b97f04f64d998b Content-Type: text/plain; charset=ISO-8859-1 is too common, a special rpc will be easy to handle, just like one command line. 2014-04-05 23:37 GMT+08:00 Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de>: > Why not simply use a with a filter? > > /js > > On Sat, Apr 05, 2014 at 11:30:25PM +0800, chong feng wrote: > > ---------- Forwarded message ---------- > > From: chong feng > > Date: 2014-04-05 22:23 GMT+08:00 > > Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement > > To: Martin Bjorklund > > > > > > I agree 'remove format sub statement from anydata'. Anydata statement > will > > be only used to define the data based on YANG schema. > > The encoding is decided by operation protocol ,such as NETCONF. > > > > BTW, I wonder whether adding a new substatment named 'path' to express > the > > data must be based on determined path. > > For example: > > rpc get-interfaces-statistics { > > > > input { > > container interfaces { > > list interface { > > key ifname; > > leaf ifname { > > type string; > > } > > } > > } > > } > > output { > > anydata data { > > path if:interfaces-state/if:interface/if:statistics; > > } > > } > > > > } > > > > > > 2014-04-04 21:22 GMT+08:00 Martin Bjorklund : > > > > This is now Y34. > > > > > > Three proposed solutions are added. > > > > > > > > > /martin > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --089e01536d4ab5b97f04f64d998b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    <get> is too common, a special rpc will be easy to h= andle, just like one command line.


    =
    2014-04-05 23:37 GMT+08:00 Juergen Schoenwaelder= <j.schoenwaelder@jacobs-university.de>:<= br>
    Why not simply use a <get> with a filt= er?

    /js

    On Sat, Apr 05, 2014 at 11:30:25PM +0800, chong feng wrote:
    > ---------- Forwarded message ----------
    > From: chong feng <fengch= ongllly@gmail.com>
    > Date: 2014-04-05 22:23 GMT+08:00
    > Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement
    > To: Martin Bjorklund <mbj@tail-f.= com>
    >
    >
    > I agree 'remove format sub statement from anydata'. Anydata st= atement will
    > be only used to define the data based on YANG schema.
    > The encoding is decided by operation protocol ,such as NETCONF.
    >
    > BTW, I wonder whether adding a new substatment named 'path' to= express the
    > data must be based on determined path.
    > For example:
    > rpc get-interfaces-statistics {
    >
    > =A0 =A0 =A0 input {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0container interfaces {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list interface {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 key ifname;
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf ifname {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type s= tring;
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0}
    > =A0 =A0 =A0 }
    > =A0 =A0 =A0 output {
    > =A0 =A0 =A0 =A0 =A0 =A0 anydata data {
    > =A0 =A0 =A0 =A0 =A0 =A0 path if:interfaces-state/if:interface/if:stati= stics;
    > =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 }
    >
    > }
    >
    >
    > 2014-04-04 21:22 GMT+08:00 Martin Bjorklund <mbj@tail-f.com>:
    >
    > This is now Y34.
    > >
    > > Three proposed solutions are added.
    > >
    > >
    > > /martin
    > >

    > _________________________________= ______________
    > netmod mailing list
    > netmod@ietf.org
    > https://www.ietf.org/mailman/listinfo/netmod


    --
    Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
    Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

    --089e01536d4ab5b97f04f64d998b-- From nobody Sat Apr 5 09:39:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A232B1A0203 for ; Sat, 5 Apr 2014 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv7ixvdMkyxw for ; Sat, 5 Apr 2014 09:39:13 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id EF5211A0162 for ; Sat, 5 Apr 2014 09:39:12 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so4766498qcx.38 for ; Sat, 05 Apr 2014 09:39:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vn6kWHoAIURtOeE6mVEgzTYOkudgF/3iLxU4arxkxh0=; b=P28yHx5ONLa6j6PGQ4ptpzK/O41AcMYTpyDMplOXTQ8rca74hsIMELJ05JG2Z4+Cb5 NTKF//46lcfutQWW4m3Mo6ZUp5xxa6FUK3Sq3zRgdB+1so5LLTrdEsm4I3kXB/pGdDqP g/+wIsEzCdoSW4jEr5twjxoGCEXbgG/cbpzNW1TMjFKDA72pP3uF0ualDtMSxTKIhFlZ WfUS4sG7KL2F3OYpva54lYPvdkfXMn0rkLLST7Q3uYsvA4oHccvkCEb2E6QTh+QkF9rV DZZxt5FZe5s4Z/TTw7C2dHHNs/zvAHhy6HcMBkVgC7TjjdF+OHa0sayAEq05BHL7/868 Uk7w== X-Gm-Message-State: ALoCoQnORDi6bPQktoLnTe+N3P2nqjBQN6/i6LbDVuJAa32PDln4aOP9rjAhsuI4DfeRk3rnVDM4 MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr3151415qge.91.1396715947714; Sat, 05 Apr 2014 09:39:07 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sat, 5 Apr 2014 09:39:07 -0700 (PDT) In-Reply-To: References: <20140404130814.GA81688@elstar.local> <20140404.152231.308141677.mbj@tail-f.com> <20140405153754.GA85829@elstar.local> Date: Sat, 5 Apr 2014 09:39:07 -0700 Message-ID: From: Andy Bierman To: chong feng Content-Type: multipart/alternative; boundary=001a1134f2beea7b7104f64e457e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qpByal3czBrQAayUaYxplwoZtYM Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 16:39:17 -0000 --001a1134f2beea7b7104f64e457e Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 5, 2014 at 8:50 AM, chong feng wrote: > is too common, a special rpc will be easy to handle, just like one > command line. > > I don't think this approach scales at all. Custom operations for retrieval should be information that cannot be easily obtained with or . See the or RPCs in the ietf-routing module for examples of appropriate custom retrieval operations. The 'path' statement looks like something that should be a vendor extension to assist a server implementation. Andy > 2014-04-05 23:37 GMT+08:00 Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>: > >> Why not simply use a with a filter? >> >> /js >> >> On Sat, Apr 05, 2014 at 11:30:25PM +0800, chong feng wrote: >> > ---------- Forwarded message ---------- >> > From: chong feng >> > Date: 2014-04-05 22:23 GMT+08:00 >> > Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement >> > To: Martin Bjorklund >> > >> > >> > I agree 'remove format sub statement from anydata'. Anydata statement >> will >> > be only used to define the data based on YANG schema. >> > The encoding is decided by operation protocol ,such as NETCONF. >> > >> > BTW, I wonder whether adding a new substatment named 'path' to express >> the >> > data must be based on determined path. >> > For example: >> > rpc get-interfaces-statistics { >> > >> > input { >> > container interfaces { >> > list interface { >> > key ifname; >> > leaf ifname { >> > type string; >> > } >> > } >> > } >> > } >> > output { >> > anydata data { >> > path if:interfaces-state/if:interface/if:statistics; >> > } >> > } >> > >> > } >> > >> > >> > 2014-04-04 21:22 GMT+08:00 Martin Bjorklund : >> > >> > This is now Y34. >> > > >> > > Three proposed solutions are added. >> > > >> > > >> > > /martin >> > > >> >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a1134f2beea7b7104f64e457e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Sat, Apr 5, 2014 at 8:50 AM, chong feng <fengchongllly@gm= ail.com> wrote:
    <get> is too common, = a special rpc will be easy to handle, just like one command line.



    I don't think= this approach scales at all.
    Custom operations for retrieval sho= uld be information that
    cannot be easily obtained with <get>= ; or <get-config>.

    See the <active-route> or <route-count> RPC= s in the ietf-routing module
    for examples of appropriate custom r= etrieval operations.

    The 'path' statement = looks like something that should be
    a vendor extension to assist a server implementation.


    Andy



    2014-04-05 23:37 = GMT+08:00 Juergen Schoenwaelder <j.schoenwaelder@jacobs= -university.de>:
    Why not simply use a <get> with a filt= er?

    /js

    On Sat, Apr 05, 2014 at 11:30:25PM +0800, chong feng wrote:
    > ---------- Forwarded message ----------
    > From: chong feng <fengchongllly@gmail.com>
    > Date: 2014-04-05 22:23 GMT+08:00
    > Subject: Re: [netmod] YANG1.1 issue: remove anyxml statement
    > To: Martin Bjorklund <mbj@tail-f.com>
    >
    >
    > I agree 'remove format sub statement from anydata'. Anydata st= atement will
    > be only used to define the data based on YANG schema.
    > The encoding is decided by operation protocol ,such as NETCONF.
    >
    > BTW, I wonder whether adding a new substatment named 'path' to= express the
    > data must be based on determined path.
    > For example:
    > rpc get-interfaces-statistics {
    >
    > =A0 =A0 =A0 input {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0container interfaces {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list interface {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 key ifname;
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf ifname {
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type s= tring;
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0}
    > =A0 =A0 =A0 }
    > =A0 =A0 =A0 output {
    > =A0 =A0 =A0 =A0 =A0 =A0 anydata data {
    > =A0 =A0 =A0 =A0 =A0 =A0 path if:interfaces-state/if:interface/if:stati= stics;
    > =A0 =A0 =A0 =A0 =A0 =A0 }
    > =A0 =A0 =A0 }
    >
    > }
    >
    >
    > 2014-04-04 21:22 GMT+08:00 Martin Bjorklund <mbj@tail-f.com>:
    >
    > This is now Y34.
    > >
    > > Three proposed solutions are added.
    > >
    > >
    > > /martin
    > >

    > _______________________________________________
    > netmod mailing list
    > netmod@ietf.org
    >
    https://www.ietf.org/mailman/listinfo/netmod


    --
    Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
    Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>


    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod


    --001a1134f2beea7b7104f64e457e-- From nobody Sat Apr 5 09:46:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55E31A03EA for ; Sat, 5 Apr 2014 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snaEol8UFb0k for ; Sat, 5 Apr 2014 09:46:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2F92C1A0422 for ; Sat, 5 Apr 2014 09:46:25 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 89D72476883; Sat, 5 Apr 2014 18:46:19 +0200 (CEST) Date: Sat, 05 Apr 2014 18:46:18 +0200 (CEST) Message-Id: <20140405.184618.418871429.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140405153754.GA85829@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dGO7VrK6GNaetKfbJ-RVuuz8Atg Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: YANG1.1 issue: remove anyxml statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 16:46:30 -0000 Andy Bierman wrote: > On Sat, Apr 5, 2014 at 8:50 AM, chong feng wrote: > > > is too common, a special rpc will be easy to handle, just like one > > command line. > > > > > > I don't think this approach scales at all. +1 > Custom operations for retrieval should be information that > cannot be easily obtained with or . +1 /martin From nobody Mon Apr 7 15:53:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FD91A02E5 for ; Mon, 7 Apr 2014 15:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1dy1rHeR-ao for ; Mon, 7 Apr 2014 15:52:55 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 138031A028B for ; Mon, 7 Apr 2014 15:52:50 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so119766qcx.41 for ; Mon, 07 Apr 2014 15:52:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=VnLGP+arEw2rk6aOYk7OH7BSFOQwDABXN46LraxeTes=; b=LUKFmfWCgZP3AvradE3pY5KgJCO2dJ3TcOsowauQAV2DK/tX9PMlyiIpaaU3UkABI+ qFQmkrA1ffsHTIRTrHZUIz7ac/VSIazqGyR1x5BLo3YUsNCT+vJp2LNxVz6A5u7/ALXw r6dZX8FuM0R32lfaQPzooAwg/UeD+iy9LIkJfI2IgmHhn83NAO7y+y+o2/EnJDL15Zz7 gM8lHRXxhqHw4UF1mn6jB1VLcA1Osp+UmDj6Y3WgZZP9wAntKWwRmYwStMDZtfKDSZuk LJfULphHOtz8CXSJglpCu0tjtmqhAf2ccZNwYOL+1VprMG6LNryGDhab9Fg/woRhU0wm 96vA== X-Gm-Message-State: ALoCoQkzr9f6crkYO/PfSO/hcQ4LS3HSI64TbU3nDRGw1k/GDJPkCUmtY5lNY6ehrSkn4pcWnmfv MIME-Version: 1.0 X-Received: by 10.140.98.116 with SMTP id n107mr200943qge.94.1396911165008; Mon, 07 Apr 2014 15:52:45 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 7 Apr 2014 15:52:44 -0700 (PDT) Date: Mon, 7 Apr 2014 15:52:44 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113a9238c626e704f67bb9bb Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rzZ5aUesSLQrUDGZh_lqdG0LBHI Subject: [netmod] Issue Y07: if-feature on keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 22:53:01 -0000 --001a113a9238c626e704f67bb9bb Content-Type: text/plain; charset=ISO-8859-1 Hi, The following issue is incorrect. The YANG compiler needs to check for any if-feature mismatch between all key leafs and their parent list node. Y07: do not allow when or if-feature on keys ** Description All keys to a list must always be implemented. Thus, the following does not make any sense and should be illegal: list foo { key "a"; leaf a { type int32; if-feature bar; // should be illegal when "/baz"; // should be illegal } } The if-feature-stmt is already allowed in YANG 1.0. How will YANG 1.0 modules compile 100% if it is now illegal to place an if-feature-stmt on a leaf. What if the leaf is inherited from a uses-stmt that has if-feature-stmts? YANG 1.1 should be specific: - conditional key leafs MUST have the same if-features (or some could be missing) as their parent list node. - all key leafs MUST have the exact same if-feature-stmts applied Andy --001a113a9238c626e704f67bb9bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    The following issue is incorrect.

    = The YANG compiler needs to check for any
    if-feature mismatch between all key leafs and their parent list node.
    <= br>
    Y07: do not allow when or if-feature on keys
    ** Description
    
      All keys to a list must always be implemented.  Thus, the following
      does not make any sense and should be illegal:
    
        list foo {
          key "a";
          leaf a {
            type int32;
            if-feature bar;  // should be illegal
            when "/baz";     // should be illegal
          }
        }
    The if-feature-stmt is already allowed in YANG 1.0.
    Ho= w will YANG 1.0 modules compile 100% if it is now
    illegal to plac= e an if-feature-stmt on a leaf. =A0What if the leaf
    is inherited = from a uses-stmt that has if-feature-stmts?

    YANG 1.1 should be specific:
    =A0 - conditiona= l key leafs MUST have the same if-features
    =A0 =A0 (or some could= be missing) as their parent list node.
    =A0- all key leafs MUST h= ave the exact same if-feature-stmts applied


    Andy

    --001a113a9238c626e704f67bb9bb-- From nobody Mon Apr 7 16:02:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B994E1A02E5 for ; Mon, 7 Apr 2014 16:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILJXraUrmZ8v for ; Mon, 7 Apr 2014 16:02:25 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3BED31A0846 for ; Mon, 7 Apr 2014 16:02:25 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so137635qcx.13 for ; Mon, 07 Apr 2014 16:02:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1hEWOYKw2575tzj3vX9RMGFipJt4tA9hsUzr2Vqo5uQ=; b=a74VVs8VJxFSFIp8MxL0opHw1vFcOBlCU7UqglzCpycLQ91azRGDHNb1h5TdDQ53ls CYFWS/FFaXhe7uDSN5UlGj5EULKTxchdj2ieWyzKQSHqrU2wT264KuRJYc1lOzyKqEwa nb5sL0bKF/omCSUyew515/57n6D7Hy+OJMJkFR8l/yniAga6xvyLZmeV8T5S40tjR8p+ G9gFnayxU6evQWx8+9715JNnt7bEMznxDNVItOetvT7aNp/g2gbT0QNjVEvROWaM/xE+ 5xJdWTiGbakzYBVeKJ9l3D/LDkI9kJamzscTvigJ7MlZ+3MufBW3UoLg93jBv5j5mzQ3 8xJA== X-Gm-Message-State: ALoCoQmNUTiGKuJpHUbXuKgz7XiugPRwwN4IlUvxdxXBWHtQn9ijILjKvYCQd0+qCTjAbCbvPBBk MIME-Version: 1.0 X-Received: by 10.229.96.199 with SMTP id i7mr323881qcn.20.1396911739425; Mon, 07 Apr 2014 16:02:19 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 7 Apr 2014 16:02:19 -0700 (PDT) Date: Mon, 7 Apr 2014 16:02:19 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1133886e02ecef04f67bdc2e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T4qJeKTiMM_dqkAIbb86YK8mf-Y Subject: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 23:02:34 -0000 --001a1133886e02ecef04f67bdc2e Content-Type: text/plain; charset=ISO-8859-1 Hi, I think the proposed solution for this issue will lead to too much cut-and-paste text. I propose that new statements be used instead called "feature-set" and "if-feature-set". feature foo; feature-set foo "expr"; ... expr == some new syntax to define the boolean expression, ... like the 'expr' in the current solution. ... no nested feature-sets; only feature boolean logic. } The feature-set-stmt would be ANDed with all the if-feature-smts. The feature-set namespace would be new in YANG 1.1: leaf X { if-feature "foo"; if-feature-set "foo"; type int32; } Andy --001a1133886e02ecef04f67bdc2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I think the proposed solution for t= his issue will lead to
    too much cut-and-paste text.
    I propose that new statements be used instead called
    "feature-set" and "if-feature-set".

    =A0 =A0feature foo;

    =A0 =A0feature-set foo &= quot;expr";
    =A0 =A0 =A0 ... expr =3D=3D some new syntax to d= efine the boolean expression,
    =A0 =A0 =A0 ... like the 'expr' in the current solution.
    =
    =A0 =A0 =A0 ... no nested feature-sets; only feature boolean logic.
    =A0 =A0}

    The feature-set-stmt would be AND= ed with all the if-feature-smts.
    The feature-set namespace would be new in YANG 1.1:

    =A0 leaf X {
    =A0 =A0 =A0if-feature "foo";
    <= div>=A0 =A0 =A0if-feature-set "foo";
    =A0 =A0 =A0type in= t32;
    =A0 }


    Andy

    --001a1133886e02ecef04f67bdc2e-- From nobody Mon Apr 7 22:59:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2946B1A012C for ; Mon, 7 Apr 2014 22:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImeqwZmC66tQ for ; Mon, 7 Apr 2014 22:59:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id DABD61A0122 for ; Mon, 7 Apr 2014 22:59:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AA9F3FF6; Tue, 8 Apr 2014 07:59:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fGSt-O7GVex5; Tue, 8 Apr 2014 07:59:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Apr 2014 07:59:11 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 206AA20033; Tue, 8 Apr 2014 07:59:11 +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 kCDxXhCi6_6u; Tue, 8 Apr 2014 07:59: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 27D442002F; Tue, 8 Apr 2014 07:59:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 508732C2B559; Tue, 8 Apr 2014 07:59:09 +0200 (CEST) Date: Tue, 8 Apr 2014 07:59:09 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140408055908.GA3796@elstar.local> Mail-Followup-To: Andy Bierman , "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) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J3jqw1ZsKlvBzeU1kBzRfRGj9aU Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 05:59:22 -0000 Andy, can you explain why the proposed text leads to "too much cut-and-paste text" and why the new proposed statements does not show this effect? /js On Mon, Apr 07, 2014 at 04:02:19PM -0700, Andy Bierman wrote: > Hi, > > I think the proposed solution for this issue will lead to > too much cut-and-paste text. > > I propose that new statements be used instead called > "feature-set" and "if-feature-set". > > feature foo; > > feature-set foo "expr"; > ... expr == some new syntax to define the boolean expression, > ... like the 'expr' in the current solution. > ... no nested feature-sets; only feature boolean logic. > } > > The feature-set-stmt would be ANDed with all the if-feature-smts. > The feature-set namespace would be new in YANG 1.1: > > leaf X { > if-feature "foo"; > if-feature-set "foo"; > type int32; > } > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Apr 7 23:11:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A647F1A00E6 for ; Mon, 7 Apr 2014 23:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTRKEtwlJc4S for ; Mon, 7 Apr 2014 23:11:01 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B21A00C6 for ; Mon, 7 Apr 2014 23:10:50 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id m5so441703qaj.34 for ; Mon, 07 Apr 2014 23:10:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=a9jmWwb0bzgzkVLjtT/xoKJVc8TrFjkgP0DS8a3Fmco=; b=P3x3t3NWeFTl2zAt3YbQyI2VyFQ+OOA7avxcp9niB7yUG/bty6kbdR91WlBA7Ml50G aFMzMe/uIR/o/KELqSV9FbfEDOCtTwvS8zQyYtSe8zIJ8W+gj2uzSMWU26RFlrzWN735 M0SD9M8UZYZYd+JEXPpour4rcdRvF7CUGW5Zv41Rr6MYcLU/fRt5sAPlP9/5cJdD9mQ2 oL09sssYHihlExi6HExJBoUGPBPMuPa/lTsg+KpKOlouEOSf4rlr7YFZ0WD4zU+dvTPW +REpEyDr/8td6Zf5mwJeV3S1BeWN6FOSKjtfLv1KMD+lSYx0uBMMuQcjefcAtcSf2cqN vYcQ== X-Gm-Message-State: ALoCoQkT2Iem+80PKBvIC/forDa3NquY34+aKF5TgpAwPf4OQgyUrbcDGeNH5UebWr3ejR92rdaX MIME-Version: 1.0 X-Received: by 10.224.165.1 with SMTP id g1mr2066025qay.16.1396937445035; Mon, 07 Apr 2014 23:10:45 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 7 Apr 2014 23:10:44 -0700 (PDT) In-Reply-To: <20140408055908.GA3796@elstar.local> References: <20140408055908.GA3796@elstar.local> Date: Mon, 7 Apr 2014 23:10:44 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e0153819a2f680504f681d800 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6gEj9FbmDGngrgyKEwdZw1UR6wQ Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 06:11:06 -0000 --089e0153819a2f680504f681d800 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 7, 2014 at 10:59 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Andy, can you explain why the proposed text leads to "too much > cut-and-paste text" and why the new proposed statements does not > show this effect? > > If complex combinations are used then the same complex expression has to be repeated everywhere the same set of conditions applies. if-feature-set foo { expr "if-feature X or if-feature Y or if-feature Z and if-feature W or if-feature A or if-feature B or if-feature C"; } leaf A { if-feature-set foo; } If the same feature set applies to 100 leafs then the long expression will be repeated 100 times. /js > > Andy > On Mon, Apr 07, 2014 at 04:02:19PM -0700, Andy Bierman wrote: > > Hi, > > > > I think the proposed solution for this issue will lead to > > too much cut-and-paste text. > > > > I propose that new statements be used instead called > > "feature-set" and "if-feature-set". > > > > feature foo; > > > > feature-set foo "expr"; > > ... expr == some new syntax to define the boolean expression, > > ... like the 'expr' in the current solution. > > ... no nested feature-sets; only feature boolean logic. > > } > > > > The feature-set-stmt would be ANDed with all the if-feature-smts. > > The feature-set namespace would be new in YANG 1.1: > > > > leaf X { > > if-feature "foo"; > > if-feature-set "foo"; > > type int32; > > } > > > > > > Andy > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --089e0153819a2f680504f681d800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 7, 2014 at 10:59 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
    Andy, can you explain why the proposed text leads to "= ;too much
    cut-and-paste text" and why the new proposed statements does not
    show this effect?


    If complex combinations are used then = the same complex expression has to be repeated everywhere
    the sam= e set of conditions applies.

    =A0 if-feature-set fo= o {
    =A0 =A0 =A0 expr "if-feature X or if-feature Y or if-feature Z an= d if-feature W or if-feature A or if-feature B or if-feature C";
    =
    =A0 }

    =A0 leaf A {
    =A0 =A0 =A0if-fe= ature-set foo;
    =A0 =A0}

    If the same feature set applies to 1= 00 leafs then the long expression will be repeated 100 times.

    /js


    Andy
    =A0
    On Mon, Apr 07, 2014 at 04:02:19PM -0700, Andy Bierman wrote:
    > Hi,
    >
    > I think the proposed solution for this issue will lead to
    > too much cut-and-paste text.
    >
    > I propose that new statements be used instead called
    > "feature-set" and "if-feature-set".
    >
    > =A0 =A0feature foo;
    >
    > =A0 =A0feature-set foo "expr";
    > =A0 =A0 =A0 ... expr =3D=3D some new syntax to define the boolean expr= ession,
    > =A0 =A0 =A0 ... like the 'expr' in the current solution.
    > =A0 =A0 =A0 ... no nested feature-sets; only feature boolean logic. > =A0 =A0}
    >
    > The feature-set-stmt would be ANDed with all the if-feature-smts.
    > The feature-set namespace would be new in YANG 1.1:
    >
    > =A0 leaf X {
    > =A0 =A0 =A0if-feature "foo";
    > =A0 =A0 =A0if-feature-set "foo";
    > =A0 =A0 =A0type int32;
    > =A0 }
    >
    >
    > Andy

    > _______________________________________________
    > netmod mailing list
    > netmod@ietf.org
    > https://www.ietf.org/mailman/listinfo/netmod


    --
    Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
    Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

    --089e0153819a2f680504f681d800-- From nobody Mon Apr 7 23:22:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA951A00AF for ; Mon, 7 Apr 2014 23:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDMAhl3eaTTE for ; Mon, 7 Apr 2014 23:22:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 82D0A1A0032 for ; Mon, 7 Apr 2014 23:22:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7835E73D; Tue, 8 Apr 2014 08:22:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6qsG1EEScqzg; Tue, 8 Apr 2014 08:22:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Apr 2014 08:22:32 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5AE8920034; Tue, 8 Apr 2014 08:22:32 +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 UcY0vItWZedC; Tue, 8 Apr 2014 08:22:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D2A12002F; Tue, 8 Apr 2014 08:22:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3FFD02C2B7C1; Tue, 8 Apr 2014 08:22:31 +0200 (CEST) Date: Tue, 8 Apr 2014 08:22:31 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140408062231.GA3899@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20140408055908.GA3796@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) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0gYNnCiMN9WeyvW9s8fb9UDEv2M Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 06:22:44 -0000 Thanks. So your proposal is about introducing named feature expressions. I did not see that initially. But would this not be the same as: feature foo { if-feature X or if-feature Y or if-feature Z and if-feature W > or if-feature A or if-feature B or if-feature C; } leaf A { if-feature foo; } That is, if we allow if-feature to take an expression, can you not simply use the existing feature statement to give such an expression a feature name? According to 7.18.1.1. feature can have an if-feature as a substatement. /js On Mon, Apr 07, 2014 at 11:10:44PM -0700, Andy Bierman wrote: > On Mon, Apr 7, 2014 at 10:59 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Andy, can you explain why the proposed text leads to "too much > > cut-and-paste text" and why the new proposed statements does not > > show this effect? > > > > > If complex combinations are used then the same complex expression has to be > repeated everywhere > the same set of conditions applies. > > if-feature-set foo { > expr "if-feature X or if-feature Y or if-feature Z and if-feature W > or if-feature A or if-feature B or if-feature C"; > } > > leaf A { > if-feature-set foo; > } > > If the same feature set applies to 100 leafs then the long expression will > be repeated 100 times. > > > /js > > > > > Andy > > > > On Mon, Apr 07, 2014 at 04:02:19PM -0700, Andy Bierman wrote: > > > Hi, > > > > > > I think the proposed solution for this issue will lead to > > > too much cut-and-paste text. > > > > > > I propose that new statements be used instead called > > > "feature-set" and "if-feature-set". > > > > > > feature foo; > > > > > > feature-set foo "expr"; > > > ... expr == some new syntax to define the boolean expression, > > > ... like the 'expr' in the current solution. > > > ... no nested feature-sets; only feature boolean logic. > > > } > > > > > > The feature-set-stmt would be ANDed with all the if-feature-smts. > > > The feature-set namespace would be new in YANG 1.1: > > > > > > leaf X { > > > if-feature "foo"; > > > if-feature-set "foo"; > > > type int32; > > > } > > > > > > > > > Andy > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 8 00:13:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4871A0156 for ; Tue, 8 Apr 2014 00:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9w-NSznmiCN for ; Tue, 8 Apr 2014 00:13:13 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8649C1A0141 for ; Tue, 8 Apr 2014 00:13:13 -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 F0A3639415B; Tue, 8 Apr 2014 09:13:05 +0200 (CEST) Date: Tue, 08 Apr 2014 09:13:05 +0200 (CEST) Message-Id: <20140408.091305.934751307307985490.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140408062231.GA3899@elstar.local> References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fuUYbq1pzDjDHNKajzGGrKd-UIE Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 07:13:18 -0000 Juergen Schoenwaelder wrote: > Thanks. So your proposal is about introducing named feature > expressions. I did not see that initially. > > But would this not be the same as: > > feature foo { > if-feature X or if-feature Y or if-feature Z and if-feature W > or if-feature A or if-feature B or if-feature C; > } Or rather: feature foo { if-feature "X or Y or Z and W or A or B or C"; } ? > leaf A { > if-feature foo; > } > > That is, if we allow if-feature to take an expression, can you not > simply use the existing feature statement to give such an expression a > feature name? According to 7.18.1.1. feature can have an if-feature as > a substatement. I think this works. /martin From nobody Tue Apr 8 00:32:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD501A014B for ; Tue, 8 Apr 2014 00:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM-iCB9Gad4E for ; Tue, 8 Apr 2014 00:32:15 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB061A0143 for ; Tue, 8 Apr 2014 00:32:15 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id 63so407430qgz.5 for ; Tue, 08 Apr 2014 00:32:09 -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 :cc:content-type; bh=fQXlxSO9efCQv3DC9OeenwfjIRrqj2iS7pNEC0CI52Q=; b=dTObRZHilo7y87VxcL9CF+HuIXvE5QEcUOGJQSsSd/ROH21JMRQujkdqy4XZ2dD290 yvzKSB7QCpMvCUPfLCKBQTE3O+HY9RankUi8WE8pPYd9wIVbgB4Oh4vDaQq5TcVGTNyY 4GeWoUkO713wXIc0CmYgDM4ucDehrMNuNDQDgvJeU1wrcENu4FAJzVAwbBP3mPtnBmcs YDIg747eYrev7zB+mj9DHZ0umphMI++PdNNhfQAVG0TpoHE6CmrKdps8c4Eqe6kM/En/ GOOSuBn07JBIFItPbOHRe/WVXQHsxvxKxmPWnjULGCNgSC9Nvnh1OvB9RY5kPLYRbHsi ci9A== MIME-Version: 1.0 X-Received: by 10.224.96.134 with SMTP id h6mr887344qan.100.1396942329387; Tue, 08 Apr 2014 00:32:09 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Tue, 8 Apr 2014 00:32:09 -0700 (PDT) In-Reply-To: <20140408.091305.934751307307985490.mbj@tail-f.com> References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> Date: Tue, 8 Apr 2014 15:32:09 +0800 Message-ID: From: chong feng To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2c44450b95504f682fb10 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iR-F6LadHEUoDEJGjYy8kK30RHc Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 07:32:20 -0000 --001a11c2c44450b95504f682fb10 Content-Type: text/plain; charset=ISO-8859-1 How about this? feature foo { if-feature union { if-feature X; if-feature Y; if-feature Z; } if-feature union { if-feature W; if-feature A; if-feature B; if-feature C; } } 2014-04-08 15:13 GMT+08:00 Martin Bjorklund : > Juergen Schoenwaelder wrote: > > Thanks. So your proposal is about introducing named feature > > expressions. I did not see that initially. > > > > But would this not be the same as: > > > > feature foo { > > if-feature X or if-feature Y or if-feature Z and if-feature W > or > if-feature A or if-feature B or if-feature C; > > } > > Or rather: > > feature foo { > if-feature "X or Y or Z and W or A or B or C"; > } > > ? > > > leaf A { > > if-feature foo; > > } > > > > That is, if we allow if-feature to take an expression, can you not > > simply use the existing feature statement to give such an expression a > > feature name? According to 7.18.1.1. feature can have an if-feature as > > a substatement. > > I think this works. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2c44450b95504f682fb10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    How about this?

    feature foo {
    =A0 =A0 if-feature union {
    =A0 =A0 =A0 =A0 =A0if-feature X;
    =A0 =A0 =A0 =A0 =A0if-feature Y;
    =A0 =A0 =A0 =A0 =A0if-feat= ure Z;
    =A0 =A0 }
    =A0 =A0 if-feature union {
    =A0 =A0 =A0 =A0 if-feature W;
    =A0 =A0 =A0 =A0 if-feature A;
    =A0 =A0 =A0 =A0 if-feature B;
    =A0 =A0 =A0 =A0 if-feature C;
    =A0 =A0 }
    }
    <= /div>


    2014-04-08 15:13 GMT+08:00 Martin Bjorklund <mbj@t= ail-f.com>:
    Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:<= br> > Thanks. So your proposal is about introducing named feature
    > expressions. I did not see that initially.
    >
    > But would this not be the same as:
    >
    > =A0 feature foo {
    > =A0 =A0 if-feature X or if-feature Y or if-feature Z and if-feature W = > or if-feature A or if-feature B or if-feature C;
    > =A0 }

    Or rather:

    =A0 feature foo {
    =A0 =A0 if-feature "X or Y or Z and W or A or B or C";
    =A0 }

    ?

    > =A0 leaf A {
    > =A0 =A0 if-feature foo;
    > =A0 }
    >
    > That is, if we allow if-feature to take an expression, can you not
    > simply use the existing feature statement to give such an expression a=
    > feature name? According to 7.18.1.1. feature can have an if-feature as=
    > a substatement.

    I think this works.


    /martin

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod

    --001a11c2c44450b95504f682fb10-- From nobody Tue Apr 8 00:46:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333F11A0143 for ; Tue, 8 Apr 2014 00:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyp0C5bWMb_E for ; Tue, 8 Apr 2014 00:45:58 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA9D1A016A for ; Tue, 8 Apr 2014 00:45:58 -0700 (PDT) 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 s387jos8007921; Tue, 8 Apr 2014 09:45:51 +0200 Message-ID: <5343A92D.9050909@mg-soft.com> Date: Tue, 08 Apr 2014 09:45:49 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> In-Reply-To: <20140408.091305.934751307307985490.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dV0_xUknGH3CskP9vTncRm8yMuc Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 07:46:03 -0000 Dne 8.4.2014 9:13, pie Martin Bjorklund: > Juergen Schoenwaelder wrote: >> Thanks. So your proposal is about introducing named feature >> expressions. I did not see that initially. >> >> But would this not be the same as: >> >> feature foo { >> if-feature X or if-feature Y or if-feature Z and if-feature W > or if-feature A or if-feature B or if-feature C; >> } > Or rather: > > feature foo { > if-feature "X or Y or Z and W or A or B or C"; > } > > ? +1 Why complicate things with named feature expressions? Jernej >> leaf A { >> if-feature foo; >> } >> >> That is, if we allow if-feature to take an expression, can you not >> simply use the existing feature statement to give such an expression a >> feature name? According to 7.18.1.1. feature can have an if-feature as >> a substatement. > I think this works. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 8 00:56:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA27E1A0194 for ; Tue, 8 Apr 2014 00:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUD5F3ih9abV for ; Tue, 8 Apr 2014 00:56:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6309F1A018B for ; Tue, 8 Apr 2014 00:56:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 52ADF73D; Tue, 8 Apr 2014 09:56:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mjyb5Oo_K6xP; Tue, 8 Apr 2014 09:56:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Apr 2014 09:56:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8935020033; Tue, 8 Apr 2014 09:56:14 +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 eVtB4YkZHamx; Tue, 8 Apr 2014 09:56:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FFE92002F; Tue, 8 Apr 2014 09:56:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29EDC2C2BB45; Tue, 8 Apr 2014 09:56:13 +0200 (CEST) Date: Tue, 8 Apr 2014 09:56:12 +0200 From: Juergen Schoenwaelder To: chong feng Message-ID: <20140408075612.GA4434@elstar.local> Mail-Followup-To: chong feng , Martin Bjorklund , netmod@ietf.org References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7i4OqvRylIE20vZp0Gr1DWR6go0 Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 07:56:34 -0000 I do understand a boolean expression. I do not at all understand what 'union' means here and what a sequence of unions means. /js On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote: > How about this? > > feature foo { > if-feature union { > if-feature X; > if-feature Y; > if-feature Z; > } > if-feature union { > if-feature W; > if-feature A; > if-feature B; > if-feature C; > } > } > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund : > > > Juergen Schoenwaelder wrote: > > > Thanks. So your proposal is about introducing named feature > > > expressions. I did not see that initially. > > > > > > But would this not be the same as: > > > > > > feature foo { > > > if-feature X or if-feature Y or if-feature Z and if-feature W > or > > if-feature A or if-feature B or if-feature C; > > > } > > > > Or rather: > > > > feature foo { > > if-feature "X or Y or Z and W or A or B or C"; > > } > > > > ? > > > > > leaf A { > > > if-feature foo; > > > } > > > > > > That is, if we allow if-feature to take an expression, can you not > > > simply use the existing feature statement to give such an expression a > > > feature name? According to 7.18.1.1. feature can have an if-feature as > > > a substatement. > > > > I think this works. > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 8 01:05:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C241A019E for ; Tue, 8 Apr 2014 01:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjDvOTXpeWwC for ; Tue, 8 Apr 2014 01:04:58 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 860201A0197 for ; Tue, 8 Apr 2014 01:04:58 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id s7so17458qap.7 for ; Tue, 08 Apr 2014 01:04:52 -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=WnufReC2LPbh1gXvOPh5ZCJKleHB7Ujs5QceUHMX0m4=; b=lMgB3ti3lc8n2VOGxzIo668xgw1bioNbTDGNTc3hBU2VtGMrP0Ein4pswRov2+ckOb wiG3v2374rxsgk6hAs9kb+kLPGRxD1NLSaotDNh1z+jaGROxf7+4v4k+xKvV21ul6xbD QvHhA5HqBgxaSoV+NPmyLl57JHgQq8ArGlw3dNOHJA+hnVuobq88MivTgnWckU2QjixP onoJsqKZss3fuZHkzV87RBaRgj0Oho5xANm8eXxWuoSZPwnbGa8bYSQ8IsMyes+pSeKt cHRwIe7CfmNuTASFM2t/6LLORZeBUoV2oRDmPPQWPy8cDA0wmeeWRHSbbJJscLm4ALqv VIOw== MIME-Version: 1.0 X-Received: by 10.140.49.233 with SMTP id q96mr2416445qga.76.1396944292446; Tue, 08 Apr 2014 01:04:52 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Tue, 8 Apr 2014 01:04:52 -0700 (PDT) In-Reply-To: <20140408075612.GA4434@elstar.local> References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> <20140408075612.GA4434@elstar.local> Date: Tue, 8 Apr 2014 16:04:52 +0800 Message-ID: From: chong feng To: Juergen Schoenwaelder , chong feng , Martin Bjorklund , netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11351ce252862004f6837057 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bHN_adYuN4VglLA1gp_09RKGj0w Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 08:05:02 -0000 --001a11351ce252862004f6837057 Content-Type: text/plain; charset=ISO-8859-1 union means the sub statements'relation is 'OR'. Just like : type union { type A; type B; type C; } 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de>: > I do understand a boolean expression. I do not at all understand what > 'union' means here and what a sequence of unions means. > > /js > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote: > > How about this? > > > > feature foo { > > if-feature union { > > if-feature X; > > if-feature Y; > > if-feature Z; > > } > > if-feature union { > > if-feature W; > > if-feature A; > > if-feature B; > > if-feature C; > > } > > } > > > > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund : > > > > > Juergen Schoenwaelder wrote: > > > > Thanks. So your proposal is about introducing named feature > > > > expressions. I did not see that initially. > > > > > > > > But would this not be the same as: > > > > > > > > feature foo { > > > > if-feature X or if-feature Y or if-feature Z and if-feature W > > or > > > if-feature A or if-feature B or if-feature C; > > > > } > > > > > > Or rather: > > > > > > feature foo { > > > if-feature "X or Y or Z and W or A or B or C"; > > > } > > > > > > ? > > > > > > > leaf A { > > > > if-feature foo; > > > > } > > > > > > > > That is, if we allow if-feature to take an expression, can you not > > > > simply use the existing feature statement to give such an expression > a > > > > feature name? According to 7.18.1.1. feature can have an if-feature > as > > > > a substatement. > > > > > > I think this works. > > > > > > > > > /martin > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11351ce252862004f6837057 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    union means the sub statements'relation is 'OR'= ;. Just like :
    type union {
    =A0 =A0 =A0type A;
    =A0 = =A0 =A0type B;
    =A0 =A0 =A0type C;
    }




    2014-04-08 15= :56 GMT+08:00 Juergen Schoenwaelder <j.schoenwaelder@ja= cobs-university.de>:
    I do understand a boolean expression. I do n= ot at all understand what
    'union' means here and what a sequence of unions means.

    /js

    On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote:
    > How about this?
    >
    > feature foo {
    > =A0 =A0 if-feature union {
    > =A0 =A0 =A0 =A0 =A0if-feature X;
    > =A0 =A0 =A0 =A0 =A0if-feature Y;
    > =A0 =A0 =A0 =A0 =A0if-feature Z;
    > =A0 =A0 }
    > =A0 =A0 if-feature union {
    > =A0 =A0 =A0 =A0 if-feature W;
    > =A0 =A0 =A0 =A0 if-feature A;
    > =A0 =A0 =A0 =A0 if-feature B;
    > =A0 =A0 =A0 =A0 if-feature C;
    > =A0 =A0 }
    > }
    >
    >
    > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund <mbj@tail-f.com>:
    >
    > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
    > > > Thanks. So your proposal is about introducing named feature<= br> > > > expressions. I did not see that initially.
    > > >
    > > > But would this not be the same as:
    > > >
    > > > =A0 feature foo {
    > > > =A0 =A0 if-feature X or if-feature Y or if-feature Z and if-= feature W > or
    > > if-feature A or if-feature B or if-feature C;
    > > > =A0 }
    > >
    > > Or rather:
    > >
    > > =A0 feature foo {
    > > =A0 =A0 if-feature "X or Y or Z and W or A or B or C";<= br> > > =A0 }
    > >
    > > ?
    > >
    > > > =A0 leaf A {
    > > > =A0 =A0 if-feature foo;
    > > > =A0 }
    > > >
    > > > That is, if we allow if-feature to take an expression, can y= ou not
    > > > simply use the existing feature statement to give such an ex= pression a
    > > > feature name? According to 7.18.1.1. feature can have an if-= feature as
    > > > a substatement.
    > >
    > > I think this works.
    > >
    > >
    > > /martin
    > >
    > > _______________________________________________
    > > netmod mailing list
    > > netmod@ietf.org
    > > https://www.ietf.org/mailman/listinfo/netmod
    > >

    --
    Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
    Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

    --001a11351ce252862004f6837057-- From nobody Tue Apr 8 02:14:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F591A01C2 for ; Tue, 8 Apr 2014 02:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gud-jY-xz4c for ; Tue, 8 Apr 2014 02:14:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 699DA1A01C7 for ; Tue, 8 Apr 2014 02:14:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 48499FEB; Tue, 8 Apr 2014 11:14:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id u69uGIJqd_SW; Tue, 8 Apr 2014 11:14:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Apr 2014 11:14:37 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DE3920033; Tue, 8 Apr 2014 11:14:37 +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 u54NMWLoeike; Tue, 8 Apr 2014 11:14:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BC212002F; Tue, 8 Apr 2014 11:14:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5D1352C2BCAC; Tue, 8 Apr 2014 11:14:36 +0200 (CEST) Date: Tue, 8 Apr 2014 11:14:36 +0200 From: Juergen Schoenwaelder To: chong feng Message-ID: <20140408091436.GA4566@elstar.local> Mail-Followup-To: chong feng , Martin Bjorklund , netmod@ietf.org References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> <20140408075612.GA4434@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) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5gOpdsyAoU3PuoEQ5f8BU-vR41E Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 09:14:48 -0000 I think Martin's proposal is way simpler and a logical extension of what we have and it does not require to introduce any new keywords. /js On Tue, Apr 08, 2014 at 04:04:52PM +0800, chong feng wrote: > union means the sub statements'relation is 'OR'. Just like : > type union { > type A; > type B; > type C; > } > > > > > 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>: > > > I do understand a boolean expression. I do not at all understand what > > 'union' means here and what a sequence of unions means. > > > > /js > > > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote: > > > How about this? > > > > > > feature foo { > > > if-feature union { > > > if-feature X; > > > if-feature Y; > > > if-feature Z; > > > } > > > if-feature union { > > > if-feature W; > > > if-feature A; > > > if-feature B; > > > if-feature C; > > > } > > > } > > > > > > > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund : > > > > > > > Juergen Schoenwaelder wrote: > > > > > Thanks. So your proposal is about introducing named feature > > > > > expressions. I did not see that initially. > > > > > > > > > > But would this not be the same as: > > > > > > > > > > feature foo { > > > > > if-feature X or if-feature Y or if-feature Z and if-feature W > > > or > > > > if-feature A or if-feature B or if-feature C; > > > > > } > > > > > > > > Or rather: > > > > > > > > feature foo { > > > > if-feature "X or Y or Z and W or A or B or C"; > > > > } > > > > > > > > ? > > > > > > > > > leaf A { > > > > > if-feature foo; > > > > > } > > > > > > > > > > That is, if we allow if-feature to take an expression, can you not > > > > > simply use the existing feature statement to give such an expression > > a > > > > > feature name? According to 7.18.1.1. feature can have an if-feature > > as > > > > > a substatement. > > > > > > > > I think this works. > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 8 02:41:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3C1A01FA for ; Tue, 8 Apr 2014 02:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFDFVhDCYWId for ; Tue, 8 Apr 2014 02:41:16 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D3D4F1A01DF for ; Tue, 8 Apr 2014 02:41:15 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so598841qae.19 for ; Tue, 08 Apr 2014 02:41:09 -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=z9heIh9J1KE97PLxp3IZ6/XFkoODbxLTCUcbSHft5KU=; b=GWO7Bdf1Az7L6XrOmh0Lnzn36Tg3X7UAg6ALIzzsiXtdNlBoSr+HBBYMCVhBQT1E9r TKGN46wuUoNtKU1DkqvuPOflLbQU6uQTEeCVXQwBTAvY9dixzz5SxliWTS2lub9W0Kq3 x2LFAltWpkbn/l8DK68cmXvWX34ZouTIK+xYo9/zRO3xIC8NzTjdfDBxHqTCzU2hyhIn 88lv/JKiAp2j3INHA5zRnElfQKDMPXjODd4tKDqXmVRIFwOVWwy+F091HjKEpJCSDgWW DoasUJWEX85dQ7FzRWIPfl5vQSKOvns719WgZBc1+R0RtXM8xAnSO+7Y1u6CqjYqizjS 4jmw== MIME-Version: 1.0 X-Received: by 10.229.219.133 with SMTP id hu5mr3014061qcb.5.1396950069705; Tue, 08 Apr 2014 02:41:09 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Tue, 8 Apr 2014 02:41:09 -0700 (PDT) In-Reply-To: <20140408091436.GA4566@elstar.local> References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> <20140408075612.GA4434@elstar.local> <20140408091436.GA4566@elstar.local> Date: Tue, 8 Apr 2014 17:41:09 +0800 Message-ID: From: chong feng To: Juergen Schoenwaelder , chong feng , Martin Bjorklund , netmod@ietf.org Content-Type: multipart/alternative; boundary=001a1133c5e6ac813604f684c8e0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mhAm_g833xblOTIa7oz44bJ5uKY Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:41:20 -0000 --001a1133c5e6ac813604f684c8e0 Content-Type: text/plain; charset=ISO-8859-1 martin's proposal also changed the meaning of 'if-feature', the argument will be changed from 'feature's name' to 'logical expression'. 'union' can be treated as a special feature name, not a new keyword, just like 'union' is 'type''s argument, not a keyword. 2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de>: > I think Martin's proposal is way simpler and a logical extension of > what we have and it does not require to introduce any new keywords. > > /js > > On Tue, Apr 08, 2014 at 04:04:52PM +0800, chong feng wrote: > > union means the sub statements'relation is 'OR'. Just like : > > type union { > > type A; > > type B; > > type C; > > } > > > > > > > > > > 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de>: > > > > > I do understand a boolean expression. I do not at all understand what > > > 'union' means here and what a sequence of unions means. > > > > > > /js > > > > > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote: > > > > How about this? > > > > > > > > feature foo { > > > > if-feature union { > > > > if-feature X; > > > > if-feature Y; > > > > if-feature Z; > > > > } > > > > if-feature union { > > > > if-feature W; > > > > if-feature A; > > > > if-feature B; > > > > if-feature C; > > > > } > > > > } > > > > > > > > > > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund : > > > > > > > > > Juergen Schoenwaelder > wrote: > > > > > > Thanks. So your proposal is about introducing named feature > > > > > > expressions. I did not see that initially. > > > > > > > > > > > > But would this not be the same as: > > > > > > > > > > > > feature foo { > > > > > > if-feature X or if-feature Y or if-feature Z and if-feature > W > > > > or > > > > > if-feature A or if-feature B or if-feature C; > > > > > > } > > > > > > > > > > Or rather: > > > > > > > > > > feature foo { > > > > > if-feature "X or Y or Z and W or A or B or C"; > > > > > } > > > > > > > > > > ? > > > > > > > > > > > leaf A { > > > > > > if-feature foo; > > > > > > } > > > > > > > > > > > > That is, if we allow if-feature to take an expression, can you > not > > > > > > simply use the existing feature statement to give such an > expression > > > a > > > > > > feature name? According to 7.18.1.1. feature can have an > if-feature > > > as > > > > > > a substatement. > > > > > > > > > > I think this works. > > > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a1133c5e6ac813604f684c8e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    martin's proposal also changed the meaning of 'if-= feature', the argument will be changed from 'feature's name'= ; to 'logical expression'.
    'union' can be treated as a = special feature name, not a new keyword, just like 'union' is '= type''s argument, not a keyword.




    2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>:
    I think Martin's proposal is way simpler= and a logical extension of
    what we have and it does not require to introduce any new keywords.

    /js

    On Tue, Apr 08, 2014 at 04:04:52PM +0800, chong feng wrote:
    > union means the sub statements'relation is 'OR'. Just like= :
    > type union {
    > =A0 =A0 =A0type A;
    > =A0 =A0 =A0type B;
    > =A0 =A0 =A0type C;
    > }
    >
    >
    >
    >
    > 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder <
    > j.schoenwaelde= r@jacobs-university.de>:
    >
    > > I do understand a boolean expression. I do not at all understand = what
    > > 'union' means here and what a sequence of unions means. > >
    > > /js
    > >
    > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote:
    > > > How about this?
    > > >
    > > > feature foo {
    > > > =A0 =A0 if-feature union {
    > > > =A0 =A0 =A0 =A0 =A0if-feature X;
    > > > =A0 =A0 =A0 =A0 =A0if-feature Y;
    > > > =A0 =A0 =A0 =A0 =A0if-feature Z;
    > > > =A0 =A0 }
    > > > =A0 =A0 if-feature union {
    > > > =A0 =A0 =A0 =A0 if-feature W;
    > > > =A0 =A0 =A0 =A0 if-feature A;
    > > > =A0 =A0 =A0 =A0 if-feature B;
    > > > =A0 =A0 =A0 =A0 if-feature C;
    > > > =A0 =A0 }
    > > > }
    > > >
    > > >
    > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund <mbj@tail-f.com>:
    > > >
    > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wro= te:
    > > > > > Thanks. So your proposal is about introducing name= d feature
    > > > > > expressions. I did not see that initially.
    > > > > >
    > > > > > But would this not be the same as:
    > > > > >
    > > > > > =A0 feature foo {
    > > > > > =A0 =A0 if-feature X or if-feature Y or if-feature= Z and if-feature W >
    > > or
    > > > > if-feature A or if-feature B or if-feature C;
    > > > > > =A0 }
    > > > >
    > > > > Or rather:
    > > > >
    > > > > =A0 feature foo {
    > > > > =A0 =A0 if-feature "X or Y or Z and W or A or B or= C";
    > > > > =A0 }
    > > > >
    > > > > ?
    > > > >
    > > > > > =A0 leaf A {
    > > > > > =A0 =A0 if-feature foo;
    > > > > > =A0 }
    > > > > >
    > > > > > That is, if we allow if-feature to take an express= ion, can you not
    > > > > > simply use the existing feature statement to give = such an expression
    > > a
    > > > > > feature name? According to 7.18.1.1. feature can h= ave an if-feature
    > > as
    > > > > > a substatement.
    > > > >
    > > > > I think this works.
    > > > >
    > > > >
    > > > > /martin
    > > > >
    > > > > _______________________________________________
    > > > > netmod mailing list
    > > > > netmod@ietf.org<= br> > > > > https://www.ietf.org/mailman/listinfo/netmod
    > > > >
    > >
    > > --
    > > Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Breme= n gGmbH
    > > Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Ge= rmany
    > > Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/&= gt;
    > >

    --
    Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
    Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

    --001a1133c5e6ac813604f684c8e0-- From nobody Tue Apr 8 02:59:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C761A0291 for ; Tue, 8 Apr 2014 02:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yesplur4LlQe for ; Tue, 8 Apr 2014 02:59:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 065651A028C for ; Tue, 8 Apr 2014 02:59:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DE77E53; Tue, 8 Apr 2014 11:59:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oaGEiE6SAvrX; Tue, 8 Apr 2014 11:59:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 8 Apr 2014 11:59:04 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12D6720033; Tue, 8 Apr 2014 11:59:04 +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 p5ceRlVKveAG; Tue, 8 Apr 2014 11:59:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 596EC2002F; Tue, 8 Apr 2014 11:59:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A351E2C2BE27; Tue, 8 Apr 2014 11:59:01 +0200 (CEST) Date: Tue, 8 Apr 2014 11:59:01 +0200 From: Juergen Schoenwaelder To: chong feng Message-ID: <20140408095900.GA4692@elstar.local> Mail-Followup-To: chong feng , Martin Bjorklund , netmod@ietf.org References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> <20140408075612.GA4434@elstar.local> <20140408091436.GA4566@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) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mIGTd6hr2pSHTMjMEbADOQ99yJE Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 09:59:18 -0000 Yes but all 1.0 if-feature statements remain valid 1.1 if-feature statements. There is a certain beauty to this. Compared to this, introducing 'union' as a special feature name is ugly with not clear benefit either. /js On Tue, Apr 08, 2014 at 05:41:09PM +0800, chong feng wrote: > martin's proposal also changed the meaning of 'if-feature', the argument > will be changed from 'feature's name' to 'logical expression'. > 'union' can be treated as a special feature name, not a new keyword, just > like 'union' is 'type''s argument, not a keyword. > > > > > 2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>: > > > I think Martin's proposal is way simpler and a logical extension of > > what we have and it does not require to introduce any new keywords. > > > > /js > > > > On Tue, Apr 08, 2014 at 04:04:52PM +0800, chong feng wrote: > > > union means the sub statements'relation is 'OR'. Just like : > > > type union { > > > type A; > > > type B; > > > type C; > > > } > > > > > > > > > > > > > > > 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de>: > > > > > > > I do understand a boolean expression. I do not at all understand what > > > > 'union' means here and what a sequence of unions means. > > > > > > > > /js > > > > > > > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote: > > > > > How about this? > > > > > > > > > > feature foo { > > > > > if-feature union { > > > > > if-feature X; > > > > > if-feature Y; > > > > > if-feature Z; > > > > > } > > > > > if-feature union { > > > > > if-feature W; > > > > > if-feature A; > > > > > if-feature B; > > > > > if-feature C; > > > > > } > > > > > } > > > > > > > > > > > > > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund : > > > > > > > > > > > Juergen Schoenwaelder > > wrote: > > > > > > > Thanks. So your proposal is about introducing named feature > > > > > > > expressions. I did not see that initially. > > > > > > > > > > > > > > But would this not be the same as: > > > > > > > > > > > > > > feature foo { > > > > > > > if-feature X or if-feature Y or if-feature Z and if-feature > > W > > > > > or > > > > > > if-feature A or if-feature B or if-feature C; > > > > > > > } > > > > > > > > > > > > Or rather: > > > > > > > > > > > > feature foo { > > > > > > if-feature "X or Y or Z and W or A or B or C"; > > > > > > } > > > > > > > > > > > > ? > > > > > > > > > > > > > leaf A { > > > > > > > if-feature foo; > > > > > > > } > > > > > > > > > > > > > > That is, if we allow if-feature to take an expression, can you > > not > > > > > > > simply use the existing feature statement to give such an > > expression > > > > a > > > > > > > feature name? According to 7.18.1.1. feature can have an > > if-feature > > > > as > > > > > > > a substatement. > > > > > > > > > > > > I think this works. > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > > Fax: +49 421 200 3103 > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 8 02:59:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1FA1A01CB for ; Tue, 8 Apr 2014 02:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlY8feVu1YA5 for ; Tue, 8 Apr 2014 02:59:41 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id B5C8E1A0285 for ; Tue, 8 Apr 2014 02:59:29 -0700 (PDT) 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 s389xMGV009622; Tue, 8 Apr 2014 11:59:22 +0200 Message-ID: <5343C878.4070800@mg-soft.com> Date: Tue, 08 Apr 2014 11:59:20 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: chong feng References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> <20140408075612.GA4434@elstar.local> <20140408091436.GA4566@elstar.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060600060808040905050902" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hZSt_BIFkORSdS7TZfrfIqgzmc8 Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:59:45 -0000 This is a multi-part message in MIME format. --------------060600060808040905050902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dne 8.4.2014 11:41, pis(e chong feng: > martin's proposal also changed the meaning of 'if-feature', the > argument will be changed from 'feature's name' to 'logical expression'. > 'union' can be treated as a special feature name, not a new keyword, > just like 'union' is 'type''s argument, not a keyword. > > It doesn't change the meaning of if-feature any more than your own solution. Both require special treatment of the same keyword's argument syntax. With the exception of your proposal being backward incompatible. "union" is a valid feature identifier in 1.0... Jernej > > > 2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder > >: > > I think Martin's proposal is way simpler and a logical extension of > what we have and it does not require to introduce any new keywords. > > /js > > On Tue, Apr 08, 2014 at 04:04:52PM +0800, chong feng wrote: > > union means the sub statements'relation is 'OR'. Just like : > > type union { > > type A; > > type B; > > type C; > > } > > > > > > > > > > 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de > >: > > > > > I do understand a boolean expression. I do not at all > understand what > > > 'union' means here and what a sequence of unions means. > > > > > > /js > > > > > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote: > > > > How about this? > > > > > > > > feature foo { > > > > if-feature union { > > > > if-feature X; > > > > if-feature Y; > > > > if-feature Z; > > > > } > > > > if-feature union { > > > > if-feature W; > > > > if-feature A; > > > > if-feature B; > > > > if-feature C; > > > > } > > > > } > > > > > > > > > > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund >: > > > > > > > > > Juergen Schoenwaelder > > wrote: > > > > > > Thanks. So your proposal is about introducing named feature > > > > > > expressions. I did not see that initially. > > > > > > > > > > > > But would this not be the same as: > > > > > > > > > > > > feature foo { > > > > > > if-feature X or if-feature Y or if-feature Z and > if-feature W > > > > or > > > > > if-feature A or if-feature B or if-feature C; > > > > > > } > > > > > > > > > > Or rather: > > > > > > > > > > feature foo { > > > > > if-feature "X or Y or Z and W or A or B or C"; > > > > > } > > > > > > > > > > ? > > > > > > > > > > > leaf A { > > > > > > if-feature foo; > > > > > > } > > > > > > > > > > > > That is, if we allow if-feature to take an expression, > can you not > > > > > > simply use the existing feature statement to give such > an expression > > > a > > > > > > feature name? According to 7.18.1.1. feature can have an > if-feature > > > as > > > > > > a substatement. > > > > > > > > > > I think this works. > > > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus > Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > > -- > 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 --------------060600060808040905050902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Dne 8.4.2014 11:41, piše chong feng:
    martin's proposal also changed the meaning of 'if-feature', the argument will be changed from 'feature's name' to 'logical expression'.
    'union' can be treated as a special feature name, not a new keyword, just like 'union' is 'type''s argument, not a keyword.



    It doesn't change the meaning of if-feature any more than your own solution. Both require special treatment of the same keyword's argument syntax. With the exception of your proposal being backward incompatible. "union" is a valid feature identifier in 1.0...

    Jernej



    2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>:
    I think Martin's proposal is way simpler and a logical extension of
    what we have and it does not require to introduce any new keywords.

    /js

    On Tue, Apr 08, 2014 at 04:04:52PM +0800, chong feng wrote:
    > union means the sub statements'relation is 'OR'. Just like :
    > type union {
    >      type A;
    >      type B;
    >      type C;
    > }
    >
    >
    >
    >
    > 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder <
    > j.schoenwaelder@jacobs-university.de>:
    >
    > > I do understand a boolean expression. I do not at all understand what
    > > 'union' means here and what a sequence of unions means.
    > >
    > > /js
    > >
    > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote:
    > > > How about this?
    > > >
    > > > feature foo {
    > > >     if-feature union {
    > > >          if-feature X;
    > > >          if-feature Y;
    > > >          if-feature Z;
    > > >     }
    > > >     if-feature union {
    > > >         if-feature W;
    > > >         if-feature A;
    > > >         if-feature B;
    > > >         if-feature C;
    > > >     }
    > > > }
    > > >
    > > >
    > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund <mbj@tail-f.com>:
    > > >
    > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
    > > > > > Thanks. So your proposal is about introducing named feature
    > > > > > expressions. I did not see that initially.
    > > > > >
    > > > > > But would this not be the same as:
    > > > > >
    > > > > >   feature foo {
    > > > > >     if-feature X or if-feature Y or if-feature Z and if-feature W >
    > > or
    > > > > if-feature A or if-feature B or if-feature C;
    > > > > >   }
    > > > >
    > > > > Or rather:
    > > > >
    > > > >   feature foo {
    > > > >     if-feature "X or Y or Z and W or A or B or C";
    > > > >   }
    > > > >
    > > > > ?
    > > > >
    > > > > >   leaf A {
    > > > > >     if-feature foo;
    > > > > >   }
    > > > > >
    > > > > > That is, if we allow if-feature to take an expression, can you not
    > > > > > simply use the existing feature statement to give such an expression
    > > a
    > > > > > feature name? According to 7.18.1.1. feature can have an if-feature
    > > as
    > > > > > a substatement.
    > > > >
    > > > > I think this works.
    > > > >
    > > > >
    > > > > /martin
    > > > >
    > > > > _______________________________________________
    > > > > netmod mailing list
    > > > > netmod@ietf.org
    > > > > https://www.ietf.org/mailman/listinfo/netmod
    > > > >
    > >
    > > --
    > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
    > > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
    > > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
    > >

    --
    Juergen Schoenwaelder           Jacobs University Bremen gGmbH
    Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
    Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>



    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod
    

    --------------060600060808040905050902-- From nobody Tue Apr 8 05:26:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E81A038B for ; Tue, 8 Apr 2014 05:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.977 X-Spam-Level: X-Spam-Status: No, score=0.977 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb6pWDeHYQYL for ; Tue, 8 Apr 2014 05:26:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 166131A005A for ; Tue, 8 Apr 2014 05:26:27 -0700 (PDT) Received: from [10.253.64.215] (unknown [213.0.81.93]) by mail.nic.cz (Postfix) with ESMTPSA id DA04013F9C7; Tue, 8 Apr 2014 14:26:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1396959986; bh=r+6BVqjBkASRtMz8SOPTsSM3+D8L/jgeQbps1b2ybNM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wEgQ7WH46NzSEosCYoR6CD0Uf5aCVFCaunI599DGFC7rBIwk3tB888D6TV7ZqBdB0 2HZr5how/bQUXyY1t7F/DpEJPtzdvxeCYeyJveN2JBjNl5WjVvnm4/GxraAcxlkyix BiBI3ho7D3z8fSrIe7P5L9tFD4C6RcpDLKsnxTww= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <5343C878.4070800@mg-soft.com> Date: Tue, 8 Apr 2014 14:26:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <896EEDD8-3E58-4BA8-A4F5-9316CD0432F6@nic.cz> References: <20140408055908.GA3796@elstar.local> <20140408062231.GA3899@elstar.local> <20140408.091305.934751307307985490.mbj@tail-f.com> <20140408075612.GA4434@elstar.local> <20140408091436.GA4566@elstar.local> <5343C878.4070800@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AGNIr9wtffBIMyZjnSCRJk6ugsk Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y01: allow boolean if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 12:26:33 -0000 On 08 Apr 2014, at 11:59, Jernej Tuljak = wrote: > Dne 8.4.2014 11:41, pi=9Ae chong feng: >> martin's proposal also changed the meaning of 'if-feature', the = argument will be changed from 'feature's name' to 'logical expression'. >> 'union' can be treated as a special feature name, not a new keyword, = just like 'union' is 'type''s argument, not a keyword. >>=20 >>=20 >=20 > It doesn't change the meaning of if-feature any more than your own = solution. Both require special treatment of the same keyword's argument = syntax. With the exception of your proposal being backward incompatible. = "union" is a valid feature identifier in 1.0=85 +1. I support Martin=92s proposal. Lada >=20 > Jernej >=20 >>=20 >>=20 >> 2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder = : >> I think Martin's proposal is way simpler and a logical extension of >> what we have and it does not require to introduce any new keywords. >>=20 >> /js >>=20 >> On Tue, Apr 08, 2014 at 04:04:52PM +0800, chong feng wrote: >> > union means the sub statements'relation is 'OR'. Just like : >> > type union { >> > type A; >> > type B; >> > type C; >> > } >> > >> > >> > >> > >> > 2014-04-08 15:56 GMT+08:00 Juergen Schoenwaelder < >> > j.schoenwaelder@jacobs-university.de>: >> > >> > > I do understand a boolean expression. I do not at all understand = what >> > > 'union' means here and what a sequence of unions means. >> > > >> > > /js >> > > >> > > On Tue, Apr 08, 2014 at 03:32:09PM +0800, chong feng wrote: >> > > > How about this? >> > > > >> > > > feature foo { >> > > > if-feature union { >> > > > if-feature X; >> > > > if-feature Y; >> > > > if-feature Z; >> > > > } >> > > > if-feature union { >> > > > if-feature W; >> > > > if-feature A; >> > > > if-feature B; >> > > > if-feature C; >> > > > } >> > > > } >> > > > >> > > > >> > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund : >> > > > >> > > > > Juergen Schoenwaelder = wrote: >> > > > > > Thanks. So your proposal is about introducing named feature >> > > > > > expressions. I did not see that initially. >> > > > > > >> > > > > > But would this not be the same as: >> > > > > > >> > > > > > feature foo { >> > > > > > if-feature X or if-feature Y or if-feature Z and = if-feature W > >> > > or >> > > > > if-feature A or if-feature B or if-feature C; >> > > > > > } >> > > > > >> > > > > Or rather: >> > > > > >> > > > > feature foo { >> > > > > if-feature "X or Y or Z and W or A or B or C"; >> > > > > } >> > > > > >> > > > > ? >> > > > > >> > > > > > leaf A { >> > > > > > if-feature foo; >> > > > > > } >> > > > > > >> > > > > > That is, if we allow if-feature to take an expression, can = you not >> > > > > > simply use the existing feature statement to give such an = expression >> > > a >> > > > > > feature name? According to 7.18.1.1. feature can have an = if-feature >> > > as >> > > > > > a substatement. >> > > > > >> > > > > I think this works. >> > > > > >> > > > > >> > > > > /martin >> > > > > >> > > > > _______________________________________________ >> > > > > netmod mailing list >> > > > > netmod@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/netmod >> > > > > >> > > >> > > -- >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, = Germany >> > > Fax: +49 421 200 3103 = >> > > >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >>=20 >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 8 08:54:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C7F1A0470 for ; Tue, 8 Apr 2014 08:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlgwU4MUELqR for ; Tue, 8 Apr 2014 08:54:20 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABFD1A0460 for ; Tue, 8 Apr 2014 08:54:20 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ih12so1099120qab.23 for ; Tue, 08 Apr 2014 08:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zJWzLc8/5s2DcGDOIKQ85I+Gx+SjAGtB1qXm7gkAlV8=; b=D9OljrX2hTU6JkWt/5rCfN/A4MdXJwh0vjjYUnofvZjacBZ6ORrS5o0gH5s9d/fIWo R/Nd4B0C4b45ywjWuhmJJcPktgiKh3HyDaaQXOA1ekwcOdmDmobf4opmjjIhRKNsFXKa 2mp0XH/MUrOowsYnm06RhJe9IuhJ/1xr1cxxsxvCvhPT/iiG7uxdhTzBhxZuV3VlutvB sb19b8YGB40mEUsnLicNWVzsdq4sstx8s7KAvSjq1/MdzYoI3wLqnEs52Rj5lXtNy6OE XcttMlZHJe8ubhWqn9NjrJUlYqyPOvKay0BpJKhUNlk15JQrzGEB7NssssPRdWERwEd+ sxdg== MIME-Version: 1.0 X-Received: by 10.224.103.197 with SMTP id l5mr5504923qao.69.1396972460329; Tue, 08 Apr 2014 08:54:20 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Tue, 8 Apr 2014 08:54:20 -0700 (PDT) Date: Tue, 8 Apr 2014 23:54:20 +0800 Message-ID: From: chong feng To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c1bdee424f4604f689ff70 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bU3tWIVOj6lKXrE0s0R8Ax4DHrE Subject: [netmod] Is necessary to express mutual exclusion of features? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 15:54:21 -0000 --001a11c1bdee424f4604f689ff70 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Sometimes a feature and other features are mutually exclusive.For example, if feature A is on, feature B must be off. Is necessary to express this relation? If not, when a node with if-feature A and if-feature B,this node will never take effect. So, I suggest add 'exclude' sub statement to feature statement. This sub statement is optional, and can have one or more instances. For example: feature foo1 { exclude foo2; exclude foo3; } if a node definition is below: leaf fooleaf { if-feature foo1; if-feature foo2; } This definition would be considered illegal. --001a11c1bdee424f4604f689ff70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi all,
    =A0 =A0 =A0 Sometimes a feature and other feat= ures are mutually exclusive.For example,
    if feature A is on, feat= ure B must be off. Is necessary to express this relation?
    If not,= when a node with if-feature A and if-feature B,this node will never take e= ffect.

    So, I suggest add 'exclude' sub statement to fe= ature statement. This sub statement is optional, and can have one or more i= nstances.

    For example:
    feature foo1 {
    =A0 =A0 =A0exclude foo2;
    =A0 =A0 =A0exclude foo3;
    = }

    if a node definition is below:

    leaf fooleaf {
    =A0 =A0 =A0 if-feature foo1;
    =A0= =A0 =A0 if-feature foo2;
    }

    This definition would be considered illegal= .
    --001a11c1bdee424f4604f689ff70-- From nobody Tue Apr 8 09:34:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D836D1A041B for ; Tue, 8 Apr 2014 09:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.022 X-Spam-Level: ** X-Spam-Status: No, score=2.022 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8S5XI3U9avz for ; Tue, 8 Apr 2014 09:34:31 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA1E1A03F9 for ; Tue, 8 Apr 2014 09:34:31 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so1026463qgd.29 for ; Tue, 08 Apr 2014 09:34:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4QfQ06jRS6Mb79vfNxz4FTPFy6A+KOpqYeoVOPL62Lg=; b=XM3Hjtdbtk+RbwTtpzo8me8TFYTgOdE0/KVR+SPnQJS8wG0HQSj0CWlVWeVXcQMZRF oSe6I8WwmalGR/oEncF7j9v1R7g65E44HJeOcf7bJJFecTZlyn49bgY+xQHyaNabgvCk 7bvb4Awn0egVNZxR9DYsh02rfuU1BRJgkpbvkOgsIOVTdenxaJTdzbxkdQ1WNohoER/x Yk0sGqYFwp5/Vlau6jPyevGyeaL7ZmPPQgapqEylkXBibxyZhaAchtOQCeJ79FurOLvx HX0guFDByWib47dlX+I4I3v4A1/qB31EvGwUhVKF/WJqbDpSJ8nbJPkPsA4g73p79mWv xZjg== X-Gm-Message-State: ALoCoQk+II7iL497D2YSDk8yMk3Cys4aiv0k7Xae5nGj/hFvpTq66aWutzCr7WPva88JCQL42CXt MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr5899955qad.88.1396974871169; Tue, 08 Apr 2014 09:34:31 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 8 Apr 2014 09:34:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Apr 2014 09:34:31 -0700 Message-ID: From: Andy Bierman To: chong feng Content-Type: multipart/alternative; boundary=089e0158a9e4f4e93604f68a8e99 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TscPzEJgy7jxFjHz6lFumZ_37nA Cc: "netmod@ietf.org" Subject: Re: [netmod] Is necessary to express mutual exclusion of features? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:34:33 -0000 --089e0158a9e4f4e93604f68a8e99 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 8, 2014 at 8:54 AM, chong feng wrote: > Hi all, > Sometimes a feature and other features are mutually exclusive.For > example, > if feature A is on, feature B must be off. Is necessary to express this > relation? > If not, when a node with if-feature A and if-feature B,this node will > never take effect. > > So, I suggest add 'exclude' sub statement to feature statement. This sub > statement is optional, and can have one or more instances. > > IMO the "if-feature" based conformance model is getting too complicated. The combined description-stmts of all the feature-stmts represent some sort of conformance model definition. A complex data model that attempts to represent a complex conformance model as a base model + some purely optional features will be a mess to use and understand, but that is how YANG works. All this hard-wired boolean conformance really makes future re-use difficult. New use-cases are likely to cause previous hard-wired feature logic to be obsolete, and prevent re-use. The conformance rules say that if-feature-stmts cannot be added or changed in an existing statement: o An "if-feature" statement may be removed, provided its node is not mandatory (Section 3.1). IMO the SMIv2 conformance model is significantly better than the YANG conformance model. It is really useful to define conformance separate from the in-line data definitions. The use-case and external reuse requirements can change independently of the data syntax and semantics. Andy For example: > feature foo1 { > exclude foo2; > exclude foo3; > } > > if a node definition is below: > > leaf fooleaf { > if-feature foo1; > if-feature foo2; > } > > This definition would be considered illegal. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --089e0158a9e4f4e93604f68a8e99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 8, 2014 at 8:54 AM, chong feng <fengchongllly@gm= ail.com> wrote:
    Hi all,
    =A0 =A0 =A0 Sometimes a featu= re and other features are mutually exclusive.For example,
    if feature A is on, feature B must be off. Is necessary to express thi= s relation?
    If not, when a node with if-feature A and if-feature = B,this node will never take effect.

    So, I suggest add 'exclude' sub statement to fe= ature statement. This sub statement is optional, and can have one or more i= nstances.



    IMO the "if-feature" based conformance model is gettin= g too complicated.
    The combined description-stmts of all the feat= ure-stmts represent some
    sort of conformance model definition. = =A0A complex data model that attempts
    to represent a complex conformance model as a base model + some
    <= div>purely optional features will be a mess to use and understand, but that=
    is how YANG works.

    All this hard-wired = boolean conformance really makes future re-use difficult.
    New use-cases are likely to cause previous hard-wired feature logic to=
    be obsolete, and prevent re-use.

    The co= nformance rules say that if-feature-stmts cannot be added or changed
    in an existing statement:
       o  An "if-feature" sta=
    tement may be removed, provided its node is not
          mandatory (Section 3.1).
    

    IMO the SMIv2 conformance model is signific= antly better than the YANG conformance
    model. =A0It is really use= ful to define conformance separate from the
    in-line data definiti= ons. =A0The use-case and external reuse requirements can change
    independently of the data syntax and semantics.


    Andy



    For example:
    feature foo1 {
    =A0 =A0 =A0exclude foo2;
    =A0 =A0 =A0exclude foo3;
    = }

    if a node definition is below:

    leaf fooleaf {
    =A0 =A0 =A0 if-feature foo1;
    =A0= =A0 =A0 if-feature foo2;
    }

    This definition would be considered illegal= .

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod


    --089e0158a9e4f4e93604f68a8e99-- From nobody Tue Apr 8 14:14:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A381A0705 for ; Tue, 8 Apr 2014 14:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.24 X-Spam-Level: *** X-Spam-Status: No, score=3.24 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, J_CHICKENPOX_37=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVFJE_qfYO0H for ; Tue, 8 Apr 2014 14:14:01 -0700 (PDT) Received: from nm33.bullet.mail.ne1.yahoo.com (nm33.bullet.mail.ne1.yahoo.com [98.138.229.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD431A040D for ; Tue, 8 Apr 2014 14:14:00 -0700 (PDT) Received: from [127.0.0.1] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 08 Apr 2014 21:14:00 -0000 Received: from [98.138.101.128] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 08 Apr 2014 21:11:00 -0000 Received: from [98.139.215.142] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 08 Apr 2014 21:10:59 -0000 Received: from [98.139.212.196] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 21:10:59 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 21:10:59 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 398617.41369.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 93037 invoked by uid 60001); 8 Apr 2014 21:10:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1396991459; bh=wbVGrbg5VUiXkROKQmFpmKNFmBiIo3GaXxLt04r+6Lw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=zqY7P7C91sQIsQW9mEeC0ARo7sBJN2TrAjkE+7WqdCOaLvFSgCLEIhdhl/tgMBTcVt21W++w6CXWNVIkM+mQB24LiWpBfDAcCwpnukLv193eDd7jbJQLo5w2Bgz9PVc7crg2zuSm9jv3hvLn3sgVlQs0oYtEmlADjNA0f0a8xR4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=i88vAwEEI6k08zgNZdvW6vnHuHJAxdPX/lY7W4kWZfp+/RSX/p3L2NKzto4iDhUD3qSupXaey9dF0UoHQo0c6HBkoLsjVgwpCrvnhsUe/ovhQVS1SFIc+uChaVnHoI7H9ihgjMROrPCLmXiF/yGYdC+5HTRLnbVZyf2Yvv3J0ic=; X-YMail-OSG: bscRr9AVM1lfAaMWzUMhEBuGuvWZ.mc9UZL_4O32MT17C13 hwOosEnPjnGbMWBDcgF.TQCIfih7jQq.RWylnIgtaJh_dZhys4rdpjFK2B7z 3sjNhEbOk5o_pXekvgMVdtLyqTuVJYPMkgL06J28pBNkns3H3GfnLFFmGPdt s8sB5W_qyPu6FM46jEtrFil2n79LVWwdpUCJdVBOHysD_jLGwoeGmCgedjF. 7kiPrDS8hhtLuFhvr_xc4tEuIbdgDSxd0gutD1y.WhzOvWIgkqAZHsNRS.D3 _bK.S_TF1gzrxkUQ5yJyh7HjBcKaFQ93MdzD6NHSw08LUGgef9TSgWhsWdlt J8m6AOsskqLhKRaet0nCQy9eV_WLbAw5paEZtxvifIO0RD.A7yRGshu7pP5f 4LukY3TOqxCzIYpk6THQ_MrK508.dosw5XQ3iou27WDYlQ22avj_mGZX6f0D H5kfoUR5F5VOeoEp.sCRuzyJ99eBjNWMxK6S_ZktKsg_.MsSQ6RVUAr3pWc_ n_ajsSAEuriP9lFNOgtcXebrvZguApCHf43aZZBCU0EZMsg36m.UzejwsTcK TIA-- Received: from [128.107.163.104] by web162501.mail.bf1.yahoo.com via HTTP; Tue, 08 Apr 2014 14:10:59 PDT X-Rocket-MIMEInfo: 002.001, SGkgTGlzYSwgCsKgCnNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4gW1N0ZXZlXSBMb2dpY2FsbHkgaXQoZGVidWdnaW5nIG91dHB1dCkgY291bGQgYmUgYXMgc2ltcGxlIGFzIHRoaXMswqAKZGVidWdnaW5nIGZlYXR1cmUgZmlsdGVyIDxBQ0w.IMKgIMKgIMKgIMKgIMKgID09PT0.IG9ubHkgZGVidWdnaW5nIG1zZyB3aXRoIEFDTCBkZWZpbmVkIHNyYy9kZXN0IGlwL3BvcnQgd2lsbCBiZSBkaXNwbGF5ZWQuCjxMaXNhPiBEbyB5b3UgbWVhbiBDTEkgY29uZmlndXJhdGlvbiBsaWtlIHRoZSBmb2xsb3dpbmcgYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <1396499226.70452.YahooMailNeo@web162501.mail.bf1.yahoo.com> Message-ID: <1396991459.70129.YahooMailNeo@web162501.mail.bf1.yahoo.com> Date: Tue, 8 Apr 2014 14:10:59 -0700 (PDT) From: steve cheng To: "Lisa Huang \(yihuan\)" , "netmod@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1748018769-344592975-1396991459=:70129" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EOM6c2OO6NGd8S0ZABKwBA5sSgk Subject: Re: [netmod] Suggestions for draft-huang-netmod-acl-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: steve cheng List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:14:05 -0000 --1748018769-344592975-1396991459=:70129 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lisa, =0A=C2=A0=0Asorry for the late reply. [Steve] Logically it(debuggi= ng output) could be as simple as this,=C2=A0=0Adebugging feature filter =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D=3D> only debugging msg with= ACL defined src/dest ip/port will be displayed.=0A Do you mean CLI c= onfiguration like the following and try to find out how to use the existing= stateless-pf.yang data model to model this case?=0Aip access-list extended= host1=0A=C2=A0 permit ip any host 10.1.1.1 log=0A=C2=A0 permit ip host 10.= 1.1.1 any log=0A=C2=A0=0Adebug access-list host1=0A=C2=A0=0A<< Steve>> =0AL= ogically it's something like this, =0Aip access host1=0A=C2=A0=C2=A0=C2=A0 = permit ip any host 10.1.1.1=0A=C2=A0=0Adebug fib pkt filter host1=0A=C2=A0= =0AWe can talk more offline if needed, =0A=C2=A0=0ASteve=0AOn Thursday, Apr= il 3, 2014 10:48 AM, Lisa Huang (yihuan) wrote:=0A =0A[= Steve] Agree, prefix list is different from access list. Well many existing= routing applications do use ACL (not prefix-list) widely.=C2=A0 =0AF= or cases that routing application use the full ACL, most likely ACL is refe= rred by name. A match leaf or leaf-list can be defined in YANG to serve the= purpose. =0Aleaf match { =0A=C2=A0 =C2=A0type "spf:spf-ref"; =0A} =0A =0A= [Steve] Logically it(debugging output) could be as simple as this,=C2=A0 = =0Adebugging feature filter =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D= =3D=3D> only debugging msg with ACL defined src/dest ip/port will be displa= yed. =0A Do you mean CLI configuration like the following and try to = find out how to use the existing stateless-pf.yang data model to model this= case? =0Aip access-list extended host1 =0A=C2=A0 permit ip any = host 10.1.1.1 log =0A=C2=A0 permit ip host 10.1.1.1 any log =0A=C2=A0 =0Ade= bug access-list host1 =0A =0A =0A =0A =0AFrom: steve cheng =0AReply-To: steve cheng =0ADate: Wednesday= , April 2, 2014 9:27 PM=0ATo: Microsoft Office User , "ne= tmod@ietf.org" =0ASubject: Re: [netmod] Suggestions for dr= aft-huang-netmod-acl-03.txt=0A =0A =0AHi Lisa, =0A =0AThanks for your reply= .=C2=A0 =0A =0APlease see inline with [Steve]. =0A =0Athanks, =0A =0ASteve = =0AOn Tuesday, April 1, 2014 4:52 PM, Lisa Huang (yihuan) wrote:=0A =0ASteve,=C2=A0Comments in line. --Lisa =0A =0AFrom: steve che= ng =0AReply-To: steve cheng = =0ADate: Saturday, March 29, 2014 11:11 AM=0ATo: "netmod@ietf.org" =0ASubject: [netmod] Suggestions for draft-huang-netmod-acl-03.txt= =0A =0A =0AHi Lisa/Alex/Andy,=0A=0AI saw current draft doesn't cover how SP= F (ACL) is applied on an interface or other client applications. =0A =0A= Section 3.3.4 of the draft=C2=A0briefly covers how to apply SPF(ACL)= =C2=A0to interface =C2=A0and also=C2=A0gives an example of how to attach a= n SPF to an interface. =0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AWe typically call these SPF(ACL) on an = interface for packet filtering as Security ACL. For example, =0Ainterface f= oo=0A=C2=A0=C2=A0=C2=A0 SPF(ACL) bar ingress/egress=0A=0AWould it make sens= e to create a new draft? =0A Yes. You could create a new module wh= ich augment interface module and add SPF(ACL) leaf list. Section 3.3.4 has = an example of that.=C2=A0 =0A=0A[Steve] OK=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AAnother kind of widel= y deployed SPF(ACL) is in other client applications. QoS, PBR, and routing = protocols such as OSPF/BGP are some examples. =0A=0A=09* For QoS/PBR/other = policy based applications, it's used for classification. For example QoS, = =0A=0A=09* class foo: match SPF (ACL), =0A=0A=09* policy bar: match class f= oo, rate limiting=0A=09* policy bar is applied on an interface ingress/egre= ss =0AOne way is: =0AImport stateless-pf { =0Aprefix "spf"; =0A} = =0A=E2=80=A6 =0AList class { =0AKey "name"; =0ALeaf "name" { =0A=E2=80=A6 = =0A} =0ALeaf-list match { =0Atype "spf:spf-ref"; =0A} =0A} =0A=0A =0A[Stev= e] we can discuss more about this if QoS/PBR YANG modeling is in the pictur= e in the future. =0A Absolutely. =0A=09* For routing pro= tocols, it's used for route/prefix filtering (not packet filtering). =0A= prefix filter is different from access list since it has less filter= ing options and don't distinguish packet source and destination. Since both= filter has similarity, prefix filtering can reuse most of the grouping def= inition in SPF(ACL). =0A[Steve] Agree, prefix list is different from access= list. Well many existing routing applications do use ACL (not prefix-list)= widely.=C2=A0 =0A=0A =0A=09* some other applications can simply use ACL (= SPF) to filter out debugging output. =0AIs this the use case describe= d in CLI? =0Aaccess-list 101 permit tcp any host 192.168.35.1 range 20 2= 1access-list 102 permit tcp host 192.168.35.1 any established =0A= =0Ainterface ethernet 0access-group 101 outaccess-group 102 in =0AIn this = case, the configuration is a single unnamed ACE in ACL but ACE name is a ma= ndatory leaf=C2=A0in=C2=A0the draft. The implementation is not in scope of = the draft, but one way to implement is to add an adapter of netconf engine = and backend. The job of the adapter is to map name based ACE(netconf config= ) to single no name ACE(system) back and forth. =0AList access-group { = =0AKey "spf-name"; =0ALeaf "spf-name" { type "spf:spf-ref"; =0A} =0ALeaf = =C2=A0dirction { =0Atype enumeration { =0AEnum "in"; =0AEnum "out"; =0A} = =0A} =0A} =0A[Steve] No, this is not the case. Logically it could be as sim= ple as this,=C2=A0 =0Adebugging feature filter =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =3D=3D=3D=3D> only debugging msg with ACL defined src/dest ip= /port will be displayed. =0A =0A =0A=0A =0A =0A =0AAny suggest= ion on how to deal with them? =0A =0A =0A =0A =0Acheers, =0A =0ASteve C= heng --1748018769-344592975-1396991459=:70129 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi Lisa,
     
    sorry for the late reply.
    [Steve] Logically it(debugging output) = could be as simple as this, 
    debugging feature filter <ACL>       =     =3D=3D=3D=3D> only debugging msg with ACL defined src/dest= ip/port will be displayed.
    <Lisa> Do you mean CLI configuration like the following an= d try to find out how to use the existing stateless-pf.yang data model to m= odel this case?
    ip access-list extended host1
      permit ip any host 10.1.1.1 log
      permit ip host 10.1.1.1 any lo= g
     
    <= div style=3D"border-width: 0px; font: 13px/19.5px Verdana, Geneva, sans-ser= if; margin: 0px; padding: 0px; text-align: left; color: rgb(51, 51, 51); text-transform: none; text-indent: 0px; letter-spacing: normal; word-spaci= ng: 0px; vertical-align: baseline; white-space: normal; outline-width: 0px;= font-size-adjust: none; font-stretch: normal; background-color: rgb(255, 2= 55, 255);">debug access-list host1
     
    << Steve>>
    Logically it's someth= ing like this,
    ip access host1
        perm= it ip any host 10.1.1.1
     
    debug fib pkt filter hos= t1
     
    We can talk more offline if needed,
     
    Steve
    On Thursday, April 3, 2014 10:48 AM, Lisa Huang (yihuan) &= lt;yihuan@cisco.com> wrote:
    =0A
    [Steve] Agree, prefix list = is different from=0A access list. Well many existing routing applications d= o use ACL (not prefix-list) widely. 
    =0A
    <Lisa>For cases that routing application use=0A the full ACL, mos= t likely ACL is referred by name. A match leaf or leaf-list can be defined = in YANG to serve the purpose.
    =0A
    =0A
    leaf match {
    = =0A
       type "spf:spf-ref";
    =0A
    }
    =0A=0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    [Steve] Logically it(debugging output) c= ould be as simple as this, 
    =0A
    debugging feature filter <ACL>      = ;     =3D=3D=3D=3D> only debugging msg with ACL defined src/de= st ip/port will be displayed.
    =0A
    <Lisa> Do you mean CLI configuration like the followi= ng and try to find out how to use the existing stateless-pf.yang data model= to model this case?
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A<= /div>=0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A
    =0A
    = =0Aip=0A access-list extended hos= t1
    =0A
    =0A =0A permit ip any host 10.1.1.1 log
    =0A
    =0A<= span style=3D"margin: 0px; padding: 0px; outline: 0px; border: 0px currentC= olor; font-family: Arial; font-size: 10pt; font-style: inherit; font-weight= : inherit; vertical-align: baseline;"> =0A permit ip host 10.1.1.1 = any log
    =0A
    =0A =
    =0A
    =0Adebug=0A acc= ess-list host1
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A

    =0A
    =0A=0A=0A
    =0A
    =0A

    =0A<= /div>=0A=0A
    =0AFrom: steve cheng <scheng98_98@yahoo.com>
    =0AReply-To: steve cheng &= lt;scheng98_98@yah= oo.com>
    =0ADate= : Wednesday, April 2, 2014 9:27 PM
    =0ATo: Microsoft Office User <yihuan@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
    =0ASubject: Re: [netmod] Suggestions for = draft-huang-netmod-acl-03.txt
    =0A
    =0A

    =0A
    =0A
    =0A
    =0A
    =0AHi Lisa,
    =0A
    =0A
    =0A
    =0A
    =0AThanks for your reply. 
    =0A=
    =0A
    = =0A
    =0A
    =0A= Please see inline with [Steve].
    =0A
    =0A
    =0A
    =0A
    =0Athanks,
    =0A
    =0A
    =0A
    =0A
    =0ASteve=
    =0A
    =0A
    =0A
    =0A
    On Tuesday, April 1, 2014 4:52 PM, Lisa Huang (yihuan) <= ;yihuan@cisco.com> wr= ote:
    =0A
    =0A
    =0A
    =0A
    =0A
    Steve, Comment= s in line. --Lisa
    =0A

    =0A
    =0A=0A
    =0AFrom: steve cheng <scheng98_98@yahoo.com>
    =0AReply-To: steve cheng <scheng98_98@yahoo.com>
    =0ADate: Saturday, March 29, 20= 14 11:11 AM
    =0ATo: "netmod@ietf.org" <= netmod@ietf.org>
    =0ASubject: [netmod] = Suggestions for draft-huang-netmod-acl-03.txt
    =0A
    = =0A

    =0A
    =0A
    =0A
    =0A
    =0AHi Lisa/Alex/Andy,
    =0A
    =0AI saw current draft doesn't cover how SPF (ACL) is applied on an interf= ace or other client applications.=0A
    =0A
    =0A
    =0A

    =0A
    =0A
    <Lisa> Section 3.3.4 of the draft b= riefly covers how to apply SPF(ACL)  to interface  and also = gives an example of how to attach an SPF to an interface.
    =0A=0A
    =0A
    =0A
    =0A
    =0A=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    =0A=0AWe typically call these SPF(ACL) on an interface for pa= cket filtering as Security ACL. For example,=0A
    =0Ainterf= ace foo
    =0A    SPF(ACL) bar ingress/egress=
    =0A
    =0AWould it make sense to create a= new draft?
    =0A
    =0A
    =0A
    <Lisa> Yes. You could cre= ate a new module which augment interface module and add SPF(ACL) leaf list.= Section 3.3.4 has an example of that. 
    =0A=0A
    =0A
    =0A
    =0A
    =0A[Steve] OK
    =0A=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    =0A
    =0AAnother kind of widely deployed SPF(A= CL) is in other client applications. QoS, PBR, and routing protocols such a= s OSPF/BGP are some examples.=0A
    =0A
    • F= or QoS/PBR/other policy based applications, it's used for classification. F= or example QoS,=0A
      =0A
      • class foo: match SPF (ACL),=
        =0A
      • policy bar: match class foo, rate limiting<= /li>
      • policy bar is applied on an interface ingress/egress
      =0A
    =0A
    =0A
    =0A
    =0A
    <Lisa>One way is:
    =0A=
    Import stateless-pf {
    =0A
    prefix "spf";
    =0A
    }=0A
    =E2=80=A6
    =0A
    List class {
    =0A
    Key "name";=
    =0A
    Leaf "name" {
    =0A
    =E2=80=A6
    =0A
    }
    =0A
    Leaf-list match {
    =0A
    type "spf:spf-ref";<= /div>=0A
    }
    =0A
    }
    =0A=0A
    =0A
    =0A
    = =0A
    =0A

    =0A
    =0A
    [Steve] we can discuss = more about this if QoS/PBR YANG modeling is in the picture in the future.=0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A
    <Lisa> Absolutely.
    =0A=0A
    =0A
    =0A
    =0A<= div class=3D"yiv9331558148yahoo_quoted" style=3D"display: block;">=0A
    =0A
    =0A
    =0A=0A
    =0A
    =0A
    =0A
    =0A
    • For routing protocols, it's used for route/= prefix filtering (not packet filtering).
    =0A
    =0A
    =0A=0A
    <Lisa> prefix filter is different from access list since it= has less filtering options and don't distinguish packet source and destina= tion. Since both filter has similarity, prefix filtering can reuse most of = the grouping definition in SPF(ACL).
    =0A
    [Steve] Agree, prefix lis= t is different from access list. Well many existing routing applications do= use ACL (not prefix-list) widely. 
    =0A=0A
    =0A
    =0A
    =0A

    =0A
    =0A
    • some other= applications can simply use ACL (SPF) to filter out debugging output.
    • =
    =0A
    =0A<L= isa>Is this the use case described in CLI?
    =0A
    =0A
    =0A=0A
    =0A
    access-list=
     101 permit tcp any host 192.168.35.1 range 20 21access-list 102 permit tcp host 192.168.35.1 any established=
    
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A
    =0A
    =0A
    =0A=0A

    =0A
    =0A=0A=
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    i=
    nterface ethernet 0access-group 10=
    1 outaccess-group 102 in=0A
    In this case, the configuration is a single unnamed A=
    CE in ACL but ACE name is a mandatory leaf in the draft. The impl=
    ementation is not in scope of the draft, but one way to implement is to add=
     an adapter of netconf engine and backend. The job of the adapter is to map=
     name based ACE(netconf config) to single no name ACE(system) back and fort=
    h. 
    =0A
    =0A
    List access-group {
    =0A
    Key "spf-name";
    =0ALeaf "spf-name" {
    =0Atype "spf:spf-ref";=0A
    <= span class=3D"yiv9331558148Apple-tab-span" style=3D"white-space: pre;">
    =0A=0A
    }
    =0A
    Leaf  dirction {
    =0A
    type enumeration {
    =0AEnum "in";
    =0A<= /span>Enum "out";
    =0A
    =0A
    }
    =0A
    }=
    =0A
    }=0A
    [Steve] No, this i= s not the case. Logically it could be as simple as this, 
    =0Adebugging feature filter &= lt;ACL>           =3D=3D=3D=3D> only debuggi= ng msg with ACL defined src/dest ip/port will be displayed.
    =0A

    =0A
    = =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=
    =0A
    =0A
    =0A=0A

    =0A
    =0A=0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A

    =0A
    =0A

    =0A
    =0A
    =0A
    =0A=
    =0A
    =0A
    =0A=0A
    =0AAny suggestion on how to deal with them?
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=
    =0Acheers,=
    =0A
    = =0A
    =0A
    =0A
    =0ASteve Cheng
    =0A
    =0A
    =0A
    =0A

    =0A
    =0A
    =0A
    = =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A
    =0A=0A<= /div>


    --1748018769-344592975-1396991459=:70129-- From nobody Fri Apr 11 06:41:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857241A069B for ; Fri, 11 Apr 2014 06:41:01 -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_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X3ni3afq4vw for ; Fri, 11 Apr 2014 06:40:59 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8AA1A0275 for ; Fri, 11 Apr 2014 06:40:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D7D7A540573 for ; Fri, 11 Apr 2014 15:40:56 +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 gXfCAErEEtNu for ; Fri, 11 Apr 2014 15:40:46 +0200 (CEST) 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 65FF0540437 for ; Fri, 11 Apr 2014 15:40:46 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 11 Apr 2014 15:40:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JOUUqP3CBXUeVAqT46LjJ-7V6Wo Subject: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:41:01 -0000 * a better model for configuration versus state data is needed ** Description In YANG 1.0, the distinction between configuration and state data is based on the value of the boolean "config" property. State data (config false) may be embedded within configuration but not vice versa. Whilst this model may be useful for closed devices with tightly controlled configuration interfaces, it is not satifactory for open systems in which NETCONF and/or RESTCONF may not have exclusive control over configurable operational parameters. In such an open system, the design of a data model must take into account that operationally used values may be different from those that appear in NETCONF/RESTCONF configuration datastores - because they may have been changed through other management interfaces or mechanisms. In such a situation, it makes no sense to bundle operational state data such as statistics with NETCONF config data that are not operationally used. Due to the backward compatibility rules for YANG 1.1, it may be impossible to enforce a new config/state-data model, but nevertheless the new model may be formulated as a recommendation, e.g. in 6087bis. ** Solution This is not a complete solution but only a suggestion of principles on which a solution could be based: - A separate (conceptual) datastore containing state data, i.e. parameters that are really used by the device is needed. No management interface will be allowed to lock the state datastore. - Every management interface (which includes NETCONF and RESTCONF) will specify the set of writable parameters, i.e. parameters that may be modified through that management interface. Some data, such as statistics, may be "absolutely read-only". - Every management interface specifies a particular discipline and workflow for eventual modifications of state data. For NETCONF this means the well-known framework of configurations datastores, commits, locks etc. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 11 07:28:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAA61A06C8 for ; Fri, 11 Apr 2014 07:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhEvtRWH7O8r for ; Fri, 11 Apr 2014 07:28:03 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id B09351A06A1 for ; Fri, 11 Apr 2014 07:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2822; q=dns/txt; s=iport; t=1397226481; x=1398436081; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/CUhiNxasYO/mkIGtjfnK9ifVco0Pc9Lo1erS3jbVLo=; b=Ua63/eaBKHCdjiuYrDKV8im+vUzhhBxdqCOnOXXyKhBl5CqQA1jeaZm5 413I4oI5zRh4aMUPAm4rmDeSYrKOPOVaqM8lEdrwC7APYMmBS5qzP3W1o IQeZnQgLaxsEIukOQ3vHyRZDr6ZrexHLg+TG+V2Mis47S0DyQ1SlLwutO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJf6R1OtJV2c/2dsb2JhbABZgwY7V70XhmRRgRsWdIIlAQEBBAEBATc0FwQCAQgRBAEBCwsJCQcnCxQJCAIEARIIE4dhDcxCEwSOOzgGBIMagRQEqyKDMYIr X-IronPort-AV: E=Sophos;i="4.97,842,1389744000"; d="scan'208";a="35013505" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 11 Apr 2014 14:28:01 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3BES2LH001971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 14:28:02 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.83]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 09:28:01 -0500 From: "Tissa Senevirathne (tsenevir)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] new issue: configuration versus state data Thread-Index: AQHPVYuw2frQ+iVQG0OFxw0R3HQODpsMeN7Q Date: Fri, 11 Apr 2014 14:28:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vcSgC4INPnZDGpv2bfR1jPRq4Jc Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:28:08 -0000 I did not understand the following, is the suggestion that YANG to have a= locking mechanism ? or commit verify approach ? or all of them - Every management interface specifies a particular discipline and workflow for eventual modifications of state data. For NETCONF this means the well-known framework of configurations datastores, commits, locks etc. -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Friday, April 11, 2014 6:41 AM To: netmod@ietf.org Subject: [netmod] new issue: configuration versus state data * a better model for configuration versus state data is needed ** Description In YANG 1.0, the distinction between configuration and state data is based = on the value of the boolean "config" property. State data (config false) ma= y be embedded within configuration but not vice versa. Whilst this model may be useful for closed devices with tightly controlled = configuration interfaces, it is not satifactory for open systems in which N= ETCONF and/or RESTCONF may not have exclusive control over configurable ope= rational parameters. In such an open system, the design of a data model must take into account t= hat operationally used values may be different from those that appear in NE= TCONF/RESTCONF configuration datastores - because they may have been change= d through other management interfaces or mechanisms. In such a situation, i= t makes no sense to bundle operational state data such as statistics with N= ETCONF config data that are not operationally used. Due to the backward compatibility rules for YANG 1.1, it may be impossible = to enforce a new config/state-data model, but nevertheless the new model ma= y be formulated as a recommendation, e.g. in 6087bis. =20 ** Solution This is not a complete solution but only a suggestion of principles on whic= h a solution could be based: - A separate (conceptual) datastore containing state data, i.e. parameters that are really used by the device is needed. No management interface will be allowed to lock the state datastore. - Every management interface (which includes NETCONF and RESTCONF) will specify the set of writable parameters, i.e. parameters that may be modified through that management interface. = =20 Some data, such as statistics, may be "absolutely read-only". - Every management interface specifies a particular discipline and workflow for eventual modifications of state data. For NETCONF this means the well-known framework of configurations datastores, commits, locks etc. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 11 08:29:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00541A06EF for ; Fri, 11 Apr 2014 08:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV6JbTPfyf6g for ; Fri, 11 Apr 2014 08:29:39 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id C8BAB1A06E7 for ; Fri, 11 Apr 2014 08:29:38 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id c9so6059910qcz.2 for ; Fri, 11 Apr 2014 08:29:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vebFBj7XckPDM8UJOuGLxXw6rWuerQUM8dWiUjjb8rQ=; b=iaGzjeGfeu/JeG00sVGvBzYI+BxUOIQrEIO07KnE9Ev0EdbguAX8RWFPk1NMkMXKZl t5zvKAatdZDJWgRfT26WxidN5AcqmsgZw4KKCdJZbQ6b3Y2a5k2f6/bMijgz+R2c5Rhp pbiCPIisDTudjtReDAn1UQFuMFEpx/T6uQZX8670HFfIlg9dgxf1CFDXwpj6rUiKNXdx DpgNnIw+fBuatQ5FNcK5gGJyigoBo9DIuIfJk4TCa1FZNV6Nz5pVh8I+67QuFCjlZlRG qapXyqSmJTYtxRaIlsMo9b6am5t7dsfSnIXCv5fuUHKcxCl33HmgHNK0yUBoXoMv2t6C 4Qfw== X-Gm-Message-State: ALoCoQm8ah24O2+zWB665jYZx/oTAetSYvoWEB62QC73Jl3mLzIgKOY/Yhg9AShUpXVzOcG/BIKF MIME-Version: 1.0 X-Received: by 10.140.94.116 with SMTP id f107mr28795979qge.64.1397230177109; Fri, 11 Apr 2014 08:29:37 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 11 Apr 2014 08:29:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Apr 2014 08:29:37 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113aa0726070e304f6c600c6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fQQEGm0xiZh1j10qkcoj6ERG6mA Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 15:29:41 -0000 --001a113aa0726070e304f6c600c6 Content-Type: text/plain; charset=ISO-8859-1 Hi, I don't think open vs. closed system has anything to do with this issue. Neither NETCONF or RESTCONF has any charter to edit operational state. This is not something YANG 1.1 can or should add to a protocol. The problem needs to be clarified. What is broken? It seems the problem stated here is an inability to identify operational values different from configuration values? This is supported by using separate objects (oper/admin-status or interface/interface-state). If and when the I2RS WG decides to use RESTCONF or NETCONF for editing operational state, then the requirements will need to be understood and changes can be made, at that time. Andy On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka wrote: > * a better model for configuration versus state data is needed > > ** Description > > In YANG 1.0, the distinction between configuration and state data is > based on the value of the boolean "config" property. State data > (config false) may be embedded within configuration but not vice > versa. > > Whilst this model may be useful for closed devices with tightly > controlled configuration interfaces, it is not satifactory for open > systems in which NETCONF and/or RESTCONF may not have exclusive > control over configurable operational parameters. > > In such an open system, the design of a data model must take into > account that operationally used values may be different from those > that appear in NETCONF/RESTCONF configuration datastores - because > they may have been changed through other management interfaces or > mechanisms. In such a situation, it makes no sense to bundle > operational state data such as statistics with NETCONF config data > that are not operationally used. > > Due to the backward compatibility rules for YANG 1.1, it may be > impossible to enforce a new config/state-data model, but nevertheless > the new model may be formulated as a recommendation, e.g. in 6087bis. > > ** Solution > > This is not a complete solution but only a suggestion of principles on > which a solution could be based: > > - A separate (conceptual) datastore containing state data, > i.e. parameters that are really used by the device is needed. No > management interface will be allowed to lock the state datastore. > - Every management interface (which includes NETCONF and > RESTCONF) will specify the set of writable parameters, > i.e. parameters that may be modified through that management interface. > Some data, such as statistics, may be "absolutely read-only". > - Every management interface specifies a particular discipline and > workflow for eventual modifications of state data. For NETCONF this > means the well-known framework of configurations datastores, > commits, locks etc. > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113aa0726070e304f6c600c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I don't think open vs. closed s= ystem has anything to do with this issue.
    Neither NETCONF or REST= CONF has any charter to edit operational state.
    This is not somet= hing YANG 1.1 can or should add to a protocol.

    The problem needs to be clarified. =A0What is broken?
    It seems the problem stated here is an inability to identify
    =
    operational values different from configuration values?
    This= is supported by using separate objects (oper/admin-status
    or interface/interface-state).

    If and when th= e I2RS WG decides to use RESTCONF or NETCONF
    for editing operatio= nal state, then the requirements will need to be understood
    and c= hanges can be made, at that time.


    Andy


    On Fr= i, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka <lhotka@nic.cz> wr= ote:
    * a better model for configuration versus st= ate data is needed

    ** Description

    In YANG 1.0, the distinction between configuration and state data is
    based on the value of the boolean "config" property. State data (config false) may be embedded within configuration but not vice
    versa.

    Whilst this model may be useful for closed devices with tightly
    controlled configuration interfaces, it is not satifactory for open
    systems in which NETCONF and/or RESTCONF may not have exclusive
    control over configurable operational parameters.

    In such an open system, the design of a data model must take into
    account that operationally used values may be different from those
    that appear in NETCONF/RESTCONF configuration datastores - because
    they may have been changed through other management interfaces or
    mechanisms. In such a situation, it makes no sense to bundle
    operational state data such as statistics with NETCONF config data
    that are not operationally used.

    Due to the backward compatibility rules for YANG 1.1, it may be
    impossible to enforce a new config/state-data model, but nevertheless
    the new model may be formulated as a recommendation, e.g. in 6087bis.

    ** Solution

    This is not a complete solution but only a suggestion of principles on
    which a solution could be based:

    - A separate (conceptual) datastore containing state data,
    =A0 i.e. parameters that are really used by the device is needed. No
    =A0 management interface will be allowed to lock the state datastore.
    - Every management interface (which includes NETCONF and
    =A0 RESTCONF) will specify the set of writable parameters,
    =A0 i.e. parameters that may be modified through that management interface.=
    =A0 Some data, such as statistics, may be "absolutely read-only".=
    - Every management interface specifies a particular discipline and
    =A0 workflow for eventual modifications of state data. For NETCONF this
    =A0 means the well-known framework of configurations datastores,
    =A0 commits, locks etc.

    --
    Ladislav Lhotka, CZ.NIC Labs
    PGP Key ID: E74E8C0C

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod

    --001a113aa0726070e304f6c600c6-- From nobody Fri Apr 11 09:20:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2F11A020D for ; Fri, 11 Apr 2014 09:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHJafAew3vGz for ; Fri, 11 Apr 2014 09:20:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 55A211A01AD for ; Fri, 11 Apr 2014 09:20:12 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9906013F9DD; Fri, 11 Apr 2014 18:20:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397233210; bh=/SWMSTZky4AkO9aaFtHx/i3n7p2mlrdqqhmjWpF0B4Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mZ4SljoLJz612uZzu8f/jBUS0Jba2SJtHisi1C07e/A0d2r+ifBrc0rtnnTyeNhk4 ZeXme18InSGmxZkzVMgz26J7nZTf/eIn5p4I9Y9D1TiZhBEHeHepEJznt1ElDr0NNL W6GUxVWXZDBVm6q4lTWIngiQpQctqhyiolAzLQzs= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 11 Apr 2014 18:20:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D29E6CE-92E7-4A12-93C2-2451CDB1A7FD@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vaGaez_duHQDiGNQYTVqVegDNmI Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:20:17 -0000 On 11 Apr 2014, at 17:29, Andy Bierman wrote: > Hi, >=20 > I don't think open vs. closed system has anything to do with this = issue. Closed systems that control all user access to a device usually try to = make sure that the configured value in fact is the state value. On a normal Linux system that runs NETCONF, the user can change = operational state by other means, e.g. via shell utilities, direct = writes to /proc, or SNMP. > Neither NETCONF or RESTCONF has any charter to edit operational state. > This is not something YANG 1.1 can or should add to a protocol.=20 >=20 > The problem needs to be clarified. What is broken? Example: container top { leaf foo { =85 } leaf bar { config false; =85 } } Now, if the operational value of =93foo=94 is not the same as the = configured value, a reply to will contain the *configured* value = of =93foo=94 and the real operational value of =93bar=94. IMO, this is = broken. The solution in some of the core modules is to separate the trees = (interfaces and interfaces-state), so at least this could be formulated = as a guideline, but I can also imagine other changes that are compatible = with YANG 1.1 restrictions.=20 > It seems the problem stated here is an inability to identify > operational values different from configuration values? > This is supported by using separate objects (oper/admin-status > or interface/interface-state). >=20 > If and when the I2RS WG decides to use RESTCONF or NETCONF > for editing operational state, then the requirements will need to be = understood > and changes can be made, at that time. This is not directly related to I2RS, although I2RS could benefit from a = general solution of this issue. Lada >=20 >=20 > Andy >=20 >=20 > On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka = wrote: > * a better model for configuration versus state data is needed >=20 > ** Description >=20 > In YANG 1.0, the distinction between configuration and state data is > based on the value of the boolean "config" property. State data > (config false) may be embedded within configuration but not vice > versa. >=20 > Whilst this model may be useful for closed devices with tightly > controlled configuration interfaces, it is not satifactory for open > systems in which NETCONF and/or RESTCONF may not have exclusive > control over configurable operational parameters. >=20 > In such an open system, the design of a data model must take into > account that operationally used values may be different from those > that appear in NETCONF/RESTCONF configuration datastores - because > they may have been changed through other management interfaces or > mechanisms. In such a situation, it makes no sense to bundle > operational state data such as statistics with NETCONF config data > that are not operationally used. >=20 > Due to the backward compatibility rules for YANG 1.1, it may be > impossible to enforce a new config/state-data model, but nevertheless > the new model may be formulated as a recommendation, e.g. in 6087bis. >=20 > ** Solution >=20 > This is not a complete solution but only a suggestion of principles on > which a solution could be based: >=20 > - A separate (conceptual) datastore containing state data, > i.e. parameters that are really used by the device is needed. No > management interface will be allowed to lock the state datastore. > - Every management interface (which includes NETCONF and > RESTCONF) will specify the set of writable parameters, > i.e. parameters that may be modified through that management = interface. > Some data, such as statistics, may be "absolutely read-only". > - Every management interface specifies a particular discipline and > workflow for eventual modifications of state data. For NETCONF this > means the well-known framework of configurations datastores, > commits, locks etc. >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 11 09:35:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F01A0659 for ; Fri, 11 Apr 2014 09:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmwtZOMQtAZA for ; Fri, 11 Apr 2014 09:35:24 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id C96721A069B for ; Fri, 11 Apr 2014 09:35:23 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so5580475qgf.6 for ; Fri, 11 Apr 2014 09:35:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zAZD7OT4pRRGuUrmIB9QkVvT+PNMEIj+2/PZQx++xgg=; b=UghN/XhJh5OcFvoNUYUkS0/HzMXMpEcHWX6386LVzJHls6By3pPHtrkSmwumVYRa+M QsLqeHCcJhx056wmjW7546kB3Ra3BxcXzSmjt+mk8VEpEBU15TpOOQ+ur8FpBgVZ4vlZ hnT77uDx2BlQGqMVjvvc3IYZonRNqI5OUu9M8tB0QXaszDxwkP7U/FNxsXzxneOkuuEn N5V9mHter74zBR56q+Fu/JRxUy33mE91BsqD5eDvL63xtNwr4OWoXw8dUi/xkb+M+KrP OYmlHDB8104c2O7BuhMYtTZHpKESksloispTZB7Jp2sc+h7uljFzNsro9qa7QhfP5EwX wBrw== X-Gm-Message-State: ALoCoQl6e5IbPLM+U2+U4LsKNTtmz/H4Uem77KEW/bPqeLwxuIfZ7j2T4OpsL7vwK1UyRlkZhOWZ MIME-Version: 1.0 X-Received: by 10.140.92.110 with SMTP id a101mr28805556qge.34.1397234122055; Fri, 11 Apr 2014 09:35:22 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 11 Apr 2014 09:35:21 -0700 (PDT) In-Reply-To: <1D29E6CE-92E7-4A12-93C2-2451CDB1A7FD@nic.cz> References: <1D29E6CE-92E7-4A12-93C2-2451CDB1A7FD@nic.cz> Date: Fri, 11 Apr 2014 09:35:21 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113ab2a8836ee904f6c6eba0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1RGiKoFQ1EGCHrzf8g6HF9G-x4Y Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:35:27 -0000 --001a113ab2a8836ee904f6c6eba0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 11, 2014 at 9:20 AM, Ladislav Lhotka wrote: > > On 11 Apr 2014, at 17:29, Andy Bierman wrote: > > > Hi, > > > > I don't think open vs. closed system has anything to do with this issue. > > Closed systems that control all user access to a device usually try to > make sure that the configured value in fact is the state value. > > On a normal Linux system that runs NETCONF, the user can change > operational state by other means, e.g. via shell utilities, direct writes > to /proc, or SNMP. > > I think it is data-model specific whether it even possible for operational values to differ from configuration. > > Neither NETCONF or RESTCONF has any charter to edit operational state. > > This is not something YANG 1.1 can or should add to a protocol. > > > > The problem needs to be clarified. What is broken? > > Example: > > container top { > leaf foo { ... } > leaf bar { config false; ... } > } > > Now, if the operational value of "foo" is not the same as the configured > value, a reply to will contain the *configured* value of "foo" and > the real operational value of "bar". IMO, this is broken. > > But NETCONF and YANG do not claim that "foo" represents anything other than the configured value. A new protocol operation could be somehow inform the client of this situation, but that doesn't change YANG. > The solution in some of the core modules is to separate the trees > (interfaces and interfaces-state), so at least this could be formulated as > a guideline, but I can also imagine other changes that are compatible with > YANG 1.1 restrictions. > > Yes -- when the data model designers know the operational values can be different, this is the traditional approach. Not sure why it is broken. > > It seems the problem stated here is an inability to identify > > operational values different from configuration values? > > This is supported by using separate objects (oper/admin-status > > or interface/interface-state). > > > > If and when the I2RS WG decides to use RESTCONF or NETCONF > > for editing operational state, then the requirements will need to be > understood > > and changes can be made, at that time. > > This is not directly related to I2RS, although I2RS could benefit from a > general solution of this issue. > > It would help to have specific solutions that maintain backward-compatibility with the YANG 1.0 config-stmt. I agree that an operational datastore is a good way to define new a non-persistent edit target, with its own validation rules. But this is something to be designed in the protocol and supported in YANG, not the other way around. Lada > > Andy > > > > > > Andy > > > > > > On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka wrote: > > * a better model for configuration versus state data is needed > > > > ** Description > > > > In YANG 1.0, the distinction between configuration and state data is > > based on the value of the boolean "config" property. State data > > (config false) may be embedded within configuration but not vice > > versa. > > > > Whilst this model may be useful for closed devices with tightly > > controlled configuration interfaces, it is not satifactory for open > > systems in which NETCONF and/or RESTCONF may not have exclusive > > control over configurable operational parameters. > > > > In such an open system, the design of a data model must take into > > account that operationally used values may be different from those > > that appear in NETCONF/RESTCONF configuration datastores - because > > they may have been changed through other management interfaces or > > mechanisms. In such a situation, it makes no sense to bundle > > operational state data such as statistics with NETCONF config data > > that are not operationally used. > > > > Due to the backward compatibility rules for YANG 1.1, it may be > > impossible to enforce a new config/state-data model, but nevertheless > > the new model may be formulated as a recommendation, e.g. in 6087bis. > > > > ** Solution > > > > This is not a complete solution but only a suggestion of principles on > > which a solution could be based: > > > > - A separate (conceptual) datastore containing state data, > > i.e. parameters that are really used by the device is needed. No > > management interface will be allowed to lock the state datastore. > > - Every management interface (which includes NETCONF and > > RESTCONF) will specify the set of writable parameters, > > i.e. parameters that may be modified through that management interface. > > Some data, such as statistics, may be "absolutely read-only". > > - Every management interface specifies a particular discipline and > > workflow for eventual modifications of state data. For NETCONF this > > means the well-known framework of configurations datastores, > > commits, locks etc. > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a113ab2a8836ee904f6c6eba0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Fri, Apr 11, 2014 at 9:20 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

    On 11 Apr 2014, at 17:29, Andy Bierman <andy@yumaworks.com> wrote:

    > Hi,
    >
    > I don't think open vs. closed system has anything to do with this = issue.

    Closed systems that control all user access to a device usually try to make= sure that the configured value in fact is the state value.

    On a normal Linux system that runs NETCONF, the user can change operational= state by other means, e.g. via shell utilities, direct writes to /proc, or= SNMP.


    I think it is data-model specific whet= her it even possible for operational
    values to differ from config= uration.

     
    The solution in some of the core modules is to separate the trees (interfac= es and interfaces-state), so at least this could be formulated as a guideli= ne, but I can also imagine other changes that are compatible with YANG 1.1 = restrictions.


    Yes -- when the data model designers k= now the operational values
    can be different, this is the traditio= nal approach.  Not sure
    why it is broken.

     
    > It seems the problem stated here is an inability to identify
    > operational values different from configuration values?
    > This is supported by using separate objects (oper/admin-status
    > or interface/interface-state).
    >
    > If and when the I2RS WG decides to use RESTCONF or NETCONF
    > for editing operational state, then the requirements will need to be u= nderstood
    > and changes can be made, at that time.

    This is not directly related to I2RS, although I2RS could benefit from a ge= neral solution of this issue.


    It would help to have specific solutio= ns that maintain backward-compatibility
    with the YANG 1.0 config-= stmt.

    I agree that an operational datastore is a g= ood way to define new a
    non-persistent edit target, with its own validation rules. But this is=
    something to be designed in the protocol and supported in YANG,<= /div>
    not the other way around.


    Lada


    Andy

     
    >
    >
    > Andy
    >
    >
    > On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
    > * a better model for configuration versus state data is needed
    >
    > ** Description
    >
    > In YANG 1.0, the distinction between configuration and state data is > based on the value of the boolean "config" property. State d= ata
    > (config false) may be embedded within configuration but not vice
    > versa.
    >
    > Whilst this model may be useful for closed devices with tightly
    > controlled configuration interfaces, it is not satifactory for open > systems in which NETCONF and/or RESTCONF may not have exclusive
    > control over configurable operational parameters.
    >
    > In such an open system, the design of a data model must take into
    > account that operationally used values may be different from those
    > that appear in NETCONF/RESTCONF configuration datastores - because
    > they may have been changed through other management interfaces or
    > mechanisms. In such a situation, it makes no sense to bundle
    > operational state data such as statistics with NETCONF config data
    > that are not operationally used.
    >
    > Due to the backward compatibility rules for YANG 1.1, it may be
    > impossible to enforce a new config/state-data model, but nevertheless<= br> > the new model may be formulated as a recommendation, e.g. in 6087bis.<= br> >
    > ** Solution
    >
    > This is not a complete solution but only a suggestion of principles on=
    > which a solution could be based:
    >
    > - A separate (conceptual) datastore containing state data,
    >   i.e. parameters that are really used by the device is needed. N= o
    >   management interface will be allowed to lock the state datastor= e.
    > - Every management interface (which includes NETCONF and
    >   RESTCONF) will specify the set of writable parameters,
    >   i.e. parameters that may be modified through that management in= terface.
    >   Some data, such as statistics, may be "absolutely read-onl= y".
    > - Every management interface specifies a particular discipline and
    >   workflow for eventual modifications of state data. For NETCONF = this
    >   means the well-known framework of configurations datastores, >   commits, locks etc.
    >
    > --
    > Ladislav Lhotka, CZ.NIC Labs
    > PGP Key ID: E74E8C0C
    >
    > _______________________________________________
    > netmod mailing list
    > netmod@ietf.org
    > https://www.ietf.org/mailman/listinfo/netmod
    >

    --
    Ladislav Lhotka, CZ.NIC Labs
    PGP Key ID: E74E8C0C





    --001a113ab2a8836ee904f6c6eba0-- From nobody Fri Apr 11 10:03:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C147C1A0716 for ; Fri, 11 Apr 2014 10:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWXC6xIQQBrZ for ; Fri, 11 Apr 2014 10:03:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 23F2C1A070D for ; Fri, 11 Apr 2014 10:03:43 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 54C4C13F9DD; Fri, 11 Apr 2014 19:03:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397235821; bh=nb4DsL8j+V3LH1vxLWXklskI1BR6mrc56YVV8GtQq3s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CIAc5BrKR3K2bcmanAa10LaD05U28mDHnP6eqEF/XKSzR09jbpRkY+ADt8QpX2C+J jIO4pIdbEeF5/nL6N4crltxHpvL4U0Q8VEPZLmR4rZdVBZG8BaDbVES+fhFzaq8YjT WcdseSVydiZ6Ib/waSiZhp/AQOjWo3XOY/oxcx3Q= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 11 Apr 2014 19:03:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0121D70E-3732-4966-8F47-138AAB6D007E@nic.cz> References: <1D29E6CE-92E7-4A12-93C2-2451CDB1A7FD@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wKNIRwwOvcXTKhGxgkEvGX8xuPQ Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:03:48 -0000 On 11 Apr 2014, at 18:35, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Apr 11, 2014 at 9:20 AM, Ladislav Lhotka = wrote: >=20 > On 11 Apr 2014, at 17:29, Andy Bierman wrote: >=20 > > Hi, > > > > I don't think open vs. closed system has anything to do with this = issue. >=20 > Closed systems that control all user access to a device usually try to = make sure that the configured value in fact is the state value. >=20 > On a normal Linux system that runs NETCONF, the user can change = operational state by other means, e.g. via shell utilities, direct = writes to /proc, or SNMP. >=20 >=20 > I think it is data-model specific whether it even possible for = operational > values to differ from configuration. In our core models this is possible for pretty much every parameter that = has any meaning outside NETCONF. >=20 > =20 > > Neither NETCONF or RESTCONF has any charter to edit operational = state. > > This is not something YANG 1.1 can or should add to a protocol. > > > > The problem needs to be clarified. What is broken? >=20 > Example: >=20 > container top { > leaf foo { =85 } > leaf bar { config false; =85 } > } >=20 > Now, if the operational value of =93foo=94 is not the same as the = configured value, a reply to will contain the *configured* value = of =93foo=94 and the real operational value of =93bar=94. IMO, this is = broken. >=20 >=20 > But NETCONF and YANG do not claim that "foo" represents anything other = than the > configured value. A new protocol operation could be somehow inform = the client > of this situation, but that doesn't change YANG. Yes, I thought get2 was intended to allow this but now after reading the = I-D again it doesn=92t seem to be the case - even with =93operational=94 = source, it will return only "config false" data. >=20 > =20 > The solution in some of the core modules is to separate the trees = (interfaces and interfaces-state), so at least this could be formulated = as a guideline, but I can also imagine other changes that are compatible = with YANG 1.1 restrictions. >=20 >=20 > Yes -- when the data model designers know the operational values > can be different, this is the traditional approach. Not sure > why it is broken. The idea of mixing config with state data is IMO broken. >=20 > =20 > > It seems the problem stated here is an inability to identify > > operational values different from configuration values? > > This is supported by using separate objects (oper/admin-status > > or interface/interface-state). > > > > If and when the I2RS WG decides to use RESTCONF or NETCONF > > for editing operational state, then the requirements will need to be = understood > > and changes can be made, at that time. >=20 > This is not directly related to I2RS, although I2RS could benefit from = a general solution of this issue. >=20 >=20 > It would help to have specific solutions that maintain = backward-compatibility > with the YANG 1.0 config-stmt. >=20 > I agree that an operational datastore is a good way to define new a > non-persistent edit target, with its own validation rules. But this is > something to be designed in the protocol and supported in YANG, > not the other way around. Well, I think there has to be *the* operational state datastore that=92s = used by all management interfaces. Is there any reliable solution for = SNMP competing with NETCONF? Lada =20 >=20 >=20 > Lada >=20 >=20 > Andy >=20 > =20 > > > > > > Andy > > > > > > On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka = wrote: > > * a better model for configuration versus state data is needed > > > > ** Description > > > > In YANG 1.0, the distinction between configuration and state data is > > based on the value of the boolean "config" property. State data > > (config false) may be embedded within configuration but not vice > > versa. > > > > Whilst this model may be useful for closed devices with tightly > > controlled configuration interfaces, it is not satifactory for open > > systems in which NETCONF and/or RESTCONF may not have exclusive > > control over configurable operational parameters. > > > > In such an open system, the design of a data model must take into > > account that operationally used values may be different from those > > that appear in NETCONF/RESTCONF configuration datastores - because > > they may have been changed through other management interfaces or > > mechanisms. In such a situation, it makes no sense to bundle > > operational state data such as statistics with NETCONF config data > > that are not operationally used. > > > > Due to the backward compatibility rules for YANG 1.1, it may be > > impossible to enforce a new config/state-data model, but = nevertheless > > the new model may be formulated as a recommendation, e.g. in = 6087bis. > > > > ** Solution > > > > This is not a complete solution but only a suggestion of principles = on > > which a solution could be based: > > > > - A separate (conceptual) datastore containing state data, > > i.e. parameters that are really used by the device is needed. No > > management interface will be allowed to lock the state datastore. > > - Every management interface (which includes NETCONF and > > RESTCONF) will specify the set of writable parameters, > > i.e. parameters that may be modified through that management = interface. > > Some data, such as statistics, may be "absolutely read-only". > > - Every management interface specifies a particular discipline and > > workflow for eventual modifications of state data. For NETCONF = this > > means the well-known framework of configurations datastores, > > commits, locks etc. > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 11 10:05:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94F21A0716 for ; Fri, 11 Apr 2014 10:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQPfTqfAJibB for ; Fri, 11 Apr 2014 10:05:54 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by ietfa.amsl.com (Postfix) with ESMTP id 818F11A0721 for ; Fri, 11 Apr 2014 10:05:54 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id q107so5633782qgd.25 for ; Fri, 11 Apr 2014 10:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=gv2aV3a2L/l6G6HsK5ACWyOfINtLcLwPXYa3ZRzKecc=; b=UtcMAwnVZ2YXdaV+CMDDiseU1nLwbVaRNLnzGncs7kEeQDFnREDsbjyk9Q7qdSVGnw BLwPD08ORfKQWP9kkVwr7qHASnJt2LSmIYtk2hrrmi95Wm0XBPT/BwFskkUGZ/p6U4/L vFznZDlif0+o/Q8Im/9bBslWCgeBMry4xDrvID2xAnwxrtmhZW8YaR1t/Sth83isWvNk +5zTP3J0AAqXDNN5nrU7Oe9802tICWDGnVH+Gf8VJtuVzsjAHrIFupZsODQKDOH2H2wO HvZARGkt7b1HJ5rqobMPB/7ZRxtGlzN4t0CEL1FosH6cSLInRrr8hIvBBSLXW8HGTvxw HlGA== X-Gm-Message-State: ALoCoQm0j/NDxIivU9T1S9rdaIBeJWWvZ8cZ7NwD6exfdJXYCgkHxMEfLLmK+zfqXyvRnuPrRW0g MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr5131450qge.91.1397235952697; Fri, 11 Apr 2014 10:05:52 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 11 Apr 2014 10:05:52 -0700 (PDT) Date: Fri, 11 Apr 2014 10:05:52 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134f2bea0d7bc04f6c758cd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ybAvGHJJLMdh5-sFPqZP8KtSsXQ Subject: [netmod] YANG 1.1 issue: notification resource identification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:05:56 -0000 --001a1134f2bea0d7bc04f6c758cd Content-Type: text/plain; charset=ISO-8859-1 Hi, Problem: NETCONF/YANG does not have a general mechanism to associate a data node with a notification event. A common feature (required by I2RS) is the ability to associate a notification with a resource instance. Solution: YANG should define some common mechanism to indicate that a notification-stmt is associated with a data resource object. This can only be done now with description-stmt text. Possible implementation: * Allow the path-stmt to be present as a sub-statement of the notification-stmt. notification interface-enabled { path "/if:interfaces/if:interface"; leaf name { type leafref { path "/if:interfaces/if:interface/if:name"; } } } The "name" leaf does not define the resource in a way that a generic tool can figure out the resource object. A tool would need to be coded separately to support each notification-stmt. The path-stmt allows the resource object to be easily identified. It would not be present unless there is a data resource object associated with the event type. Andy --001a1134f2bea0d7bc04f6c758cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    Problem:

    = =A0NETCONF/YANG does not have a general mechanism
    =A0to associate= a data node with a notification event.
    =A0A common feature (requ= ired by I2RS) is the ability
    =A0to associate a notification with a resource instance.
    Solution:

    =A0YANG should define some c= ommon mechanism to indicate
    =A0that a notification-stmt is associ= ated with a data resource object.
    =A0This can only be done now with description-stmt text.
    =A0Possible implementation:

    =A0 =A0* A= llow the path-stmt to be present as a sub-statement
    =A0 =A0 =A0of= the notification-stmt.

    =A0 notification interface-enabled {
    =A0 =A0 = =A0 path "/if:interfaces/if:interface";
    =A0 =A0 =A0 lea= f name {
    =A0 =A0 =A0 =A0 type leafref {
    =A0 =A0 =A0 =A0= =A0 =A0path "/if:interfaces/if:interface/if:name";
    =A0 =A0 =A0 =A0 }
    =A0 =A0 =A0}
    =A0 }
    The "name" leaf does not define the resource in a way= that
    a generic tool can figure out the resource object. =A0A too= l would
    need to be coded separately to support each notification-stmt.
    The path-stmt allows the resource object to be easily identifi= ed.
    It would not be present unless there is a data resource objec= t
    associated with the event type.


    Andy

    --001a1134f2bea0d7bc04f6c758cd-- From nobody Fri Apr 11 10:20:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A3F1A071C for ; Fri, 11 Apr 2014 10:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IY69WlxgDTR for ; Fri, 11 Apr 2014 10:20:24 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 64C991A0726 for ; Fri, 11 Apr 2014 10:20:24 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so6198449qcx.20 for ; Fri, 11 Apr 2014 10:20:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=qyum4BfQN2YHQ7+9YNG55ta5llfEaVsCi83jTeJfyks=; b=io2jLMHhgJQpImOg5Pa0edMfun8TetrsoZ6+LY0z2sywtg6mB3H8fcd8LrdC1G+OYA ic4BDw7w3vVdGsPwjxFgBgfDcRZN8D9J4ZZr7Zki7VjKd6ZI4SUqpGEa+6X9TP7qCS0l SUYUr9cOtkbYvF24J2tgSI5qpjEoapQ0nM6iel6vxlhNLK9Nsu68QFGRJh1AkwDiHPMo KaoIPJ5CN9rqh0nPDyhLBsfRMlrgJOm7tdbtrnaN8qc9A86YS9BLEIjzYfTxyEPqjnPC HCN2DtiyHXyo6A/+GVkog1deE21glF1aIJZSmenwDxcBiyVVIHEjp+ApSGsr0F551d8H OoRg== X-Gm-Message-State: ALoCoQnAm5mxND0MJuroaskZBxIzHjixZZ+0mk6bvhxB1zEijeabxQ+rHt+xL6rdGCmXiUVLqy3n MIME-Version: 1.0 X-Received: by 10.224.125.194 with SMTP id z2mr420887qar.99.1397236822794; Fri, 11 Apr 2014 10:20:22 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 11 Apr 2014 10:20:22 -0700 (PDT) Date: Fri, 11 Apr 2014 10:20:22 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c206887d724504f6c78cdd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GslL5kniB2ut8THUiImZSpYPCMg Subject: [netmod] YANG 1.1 issue: notification reuse X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:20:26 -0000 --001a11c206887d724504f6c78cdd Content-Type: text/plain; charset=ISO-8859-1 Hi, Problem: YANG notficaition-stmt allows other modules to augment an event with data but there is no common way to derive new event types from existing event types. Solution: A mechanism is needed in YANG to allow new notifications to be defined that extend existing notifications. Conceptually, the contents of a base notification are added the new notification Possible implementation: * Add a base-notification statement as a sub-statement of notification-stmt notification interface-event { path "/if:interfaces/if:interface"; leaf name { type leafref { path "/if:interfaces/if:interface/if:name"; } } } notification interface-enabled { base-notification "if:interface-event"; // new objects can be added here } notification interface-disabled { base-notification "if:interface-event"; // new objects can be added here } The YANG compiler treats the base-notification-stmt as a conceptual "uses" statement and the base notification is treated like a grouping, except the entire contents are used, not just data-def-stmts. Andy --001a11c206887d724504f6c78cdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    Problem:

    = =A0 YANG notficaition-stmt allows other modules to augment an event
    =A0 with data but there is no common way to derive new event types
    =
    =A0 from existing event types.

    Solution:

    =A0 A mechanism is needed in YANG to allow new notification= s to be
    =A0 defined that extend existing notifications. Conceptua= lly, the contents
    =A0 of a base notification are added the new notification
    Possible implementation:

    =A0 =A0* Add= a base-notification statement as a sub-statement of notification-stmt

    = =A0 notification interface-event {
    =A0 =A0 =A0 path "/if:interfaces/if:interface&= quot;;
    =A0 =A0 =A0 leaf= name {
    =A0= =A0 =A0 =A0 type leafref {
    =A0 =A0 =A0 =A0 =A0 =A0path "/if:interfaces/if:interface/if:name"= ;
    =A0 =A0 = =A0 =A0 }
    = =A0 =A0 =A0}
    =A0 }

    =A0 n= otification interface-enabled {
    =A0 =A0 =A0base-notification "if:interface-event";
    =A0 =A0 =A0// new objects= can be added here
    =A0 }

    <= /div>
    =A0 no= tification interface-disabled {
    =A0 =A0 =A0base-notification &quo= t;if:interface-event";
    =A0 =A0 =A0// new objects can be added here
    =A0 }

    The YANG compiler tre= ats the base-notification-stmt as a conceptual
    "uses"= statement and the base notification is treated like a grouping,
    except the entire con= tents are used, not just data-def-stmts.


    Andy



    --001a11c206887d724504f6c78cdd-- From nobody Fri Apr 11 10:58:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33D71A035D for ; Fri, 11 Apr 2014 10:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPCapcIyNDVa for ; Fri, 11 Apr 2014 10:58:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 117E71A0345 for ; Fri, 11 Apr 2014 10:58:12 -0700 (PDT) Received: from [192.168.1.107] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5C23E2762338; Fri, 11 Apr 2014 13:58:10 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6C02F275-4BC5-4C6D-B09E-7104D48ABEF9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 11 Apr 2014 13:58:11 -0400 Message-Id: <8561EF84-52D4-4FF3-AD0C-89C4C32E7822@lucidvision.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j3WTK9jMakpTj2lISM8behgE6Fc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: notification resource identification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:58:17 -0000 --Apple-Mail=_6C02F275-4BC5-4C6D-B09E-7104D48ABEF9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 I like this idea. On Apr 11, 2014:1:05 PM, at 1:05 PM, Andy Bierman wrote: > Hi, > > Problem: > > NETCONF/YANG does not have a general mechanism > to associate a data node with a notification event. > A common feature (required by I2RS) is the ability > to associate a notification with a resource instance. > > Solution: > > YANG should define some common mechanism to indicate > that a notification-stmt is associated with a data resource object. > This can only be done now with description-stmt text. > > Possible implementation: > > * Allow the path-stmt to be present as a sub-statement > of the notification-stmt. > > notification interface-enabled { > path "/if:interfaces/if:interface"; > leaf name { > type leafref { > path "/if:interfaces/if:interface/if:name"; > } > } > } > > The "name" leaf does not define the resource in a way that > a generic tool can figure out the resource object. A tool would > need to be coded separately to support each notification-stmt. > > The path-stmt allows the resource object to be easily identified. > It would not be present unless there is a data resource object > associated with the event type. > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_6C02F275-4BC5-4C6D-B09E-7104D48ABEF9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTSC0zAAoJEPcO+I7eiUJZnmIP/imENLnJKdk55qYk4zXdKPio 7Ah7ZI3KswIU7Z69G8bUgrqB2jw1YDmoPRMkioTLGPhJktjetzFucCCZ77azfxjE 8P2cMj9SKqwgMGLlI0jTs1kvADe97de83pQhckMfLksRomAvA0NtlQbzRTeigcEB Rii7Ddt88787YTc/xxgv8RONs9CW1metYXwp1oVZW6076a/wQj0/v5lyFLpCsLmE oKF2K+E9JXCj51uh5cdNtogLKYu/YUDrio3G2LxqDFWbqAfAX6h/zHQTotgNVN+g 2qKCCywCnwwRI6hLtyXYZqEHY+yFfBtCpg8UZscTQ9/nqUSThBaqnVq2JqSb2j/g CEUipMIV0ToxZO+YV/+12yNXHYIe2g5hIcjzS8Hwi9fcuzukv4+qQNMNK+KU9EUf TYg7KI3mEZaD0Ty+ueWKJxFwxoFlJ0S44egtbWaIo6OI+26w2fdxalCf2fbOicgV NdZM4BljvM7hWYLYbv00rPbNX8Fkc3ni5MsXgNoWm0lFMDQbhNGSEVx8RKKa7woO hhrB3NZXlJ1xmMFuCR72ukMpQTB+Sy3NkEIX/ibteTMMl2qhjOGzeCbfjRNC1sEa Qj817YleeoNE60zsOGunW6ydlMnYkjVUxz06El2LtdKBkZZnM1P3Rv9xm7iAcfmb 8BVYYXXLpjPbmoHyzxBR =I8SI -----END PGP SIGNATURE----- --Apple-Mail=_6C02F275-4BC5-4C6D-B09E-7104D48ABEF9-- From nobody Fri Apr 11 11:34:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1F61A02E8 for ; Fri, 11 Apr 2014 11:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6iysRZawST2 for ; Fri, 11 Apr 2014 11:34:21 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8D1A0219 for ; Fri, 11 Apr 2014 11:34:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qW6vgkROINhLP9RlVR32cakljAQoU7chWPnSrcLAAmnQMSeDXhVAfFk5mej8fAjN; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WYgHL-00029L-8X for netmod@ietf.org; Fri, 11 Apr 2014 14:34:19 -0400 Received: from 99.101.142.107 by webmail.earthlink.net with HTTP; Fri, 11 Apr 2014 14:34:18 -0400 Message-ID: <69078.1397241259134.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Fri, 11 Apr 2014 11:34:18 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbcc38ac4bda72ea52f051326696eef0e4d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rhv-7yDGFQcysMtUEy7_u4KXiQM Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:34:26 -0000 Hi - >From: Ladislav Lhotka >Sent: Apr 11, 2014 10:03 AM >To: Andy Bierman >Cc: "netmod@ietf.org" >Subject: Re: [netmod] new issue: configuration versus state data ... >Well, I think there has to be *the* operational state datastore >that=E2=80=99s used by all management interfaces. ... At the bottom of the pile, on most systems there is. The problems are that: (1) the nature of this datastore may actually be different for different resources on the same system (2) the relationship between this datastore and data/information models mapped onto it is (to varying degrees) both model- and implementation-specific (3) the various models mapped onto the datastore sometimes impose conflicting requirements, and the various sets of instrumentation accessing the datastore often ignore each other's needs It would be lovely to have a way of formally expressing the relationships for a given system with a particular configuration (since the relationships depend on the exact combination of hardware and software and their configuration), so that the behaviour of that system might be rigorously described. But I suspect the reality would turn out to be that for too many "open" systems, the formal description would only tell you that the system's behaviour either not fully deterministic, or that the inter-relationships are so complicated that the formal description is unhelpful. Randy From nobody Fri Apr 11 11:56:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B2F1A0765 for ; Fri, 11 Apr 2014 11:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzbvGwdzi4mh for ; Fri, 11 Apr 2014 11:56:23 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id 110FF1A075F for ; Fri, 11 Apr 2014 11:56:22 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so5767883qgf.6 for ; Fri, 11 Apr 2014 11:56:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QkKT2BT0+sDXlNHDCdNu4QiC5Kpi5hx7F5DFlLlVd/4=; b=Vd1Q1S8tcYPv5EIZh8vpZtrHYeuQIZP79CHom6S8/9+iYB+PYSRtvEshWVPFlZpwH8 cAAfR6M17pD/chclm6OAQPFAtvQZye6sREOuEJY20TeQpyi59l96+2KV2OErB90B9S5i DCYea+KuukgsMDolnu2PMe0UZ9aE1W+b3KUF4tgqlcnXaqFdQrjrtaX+IIzCg9j2TmFv aGOrkQ6sKDDxV25FjfelBkMYCP3EzxuZvu4AC/9fXi0bkOoTDhsrDWqHF9AwF2eRnd6v vulgnD3fWQTCIEuE2PZJVbywnXk5y8P/FGJefZfoaKg0pg6RQvT9/2mEKZPaau8KmuTA 6MVw== X-Gm-Message-State: ALoCoQmH08VNIO1xp340PhBqcpkEQd/KpdONWinmfTRfJh7hO+X24Nz/slMvc9ryjpI06dGiAfN0 MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr5884928qge.91.1397242581272; Fri, 11 Apr 2014 11:56:21 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 11 Apr 2014 11:56:21 -0700 (PDT) In-Reply-To: <0121D70E-3732-4966-8F47-138AAB6D007E@nic.cz> References: <1D29E6CE-92E7-4A12-93C2-2451CDB1A7FD@nic.cz> <0121D70E-3732-4966-8F47-138AAB6D007E@nic.cz> Date: Fri, 11 Apr 2014 11:56:21 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134f2beb8dae504f6c8e3bd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/O6mxLTHcyowUWWHEPOrGYMRNV6o Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:56:27 -0000 --001a1134f2beb8dae504f6c8e3bd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 11, 2014 at 10:03 AM, Ladislav Lhotka wrote: > > On 11 Apr 2014, at 18:35, Andy Bierman wrote: > > > > > > > > > On Fri, Apr 11, 2014 at 9:20 AM, Ladislav Lhotka wrote: > > > > On 11 Apr 2014, at 17:29, Andy Bierman wrote: > > > > > Hi, > > > > > > I don't think open vs. closed system has anything to do with this > issue. > > > > Closed systems that control all user access to a device usually try to > make sure that the configured value in fact is the state value. > > > > On a normal Linux system that runs NETCONF, the user can change > operational state by other means, e.g. via shell utilities, direct writes > to /proc, or SNMP. > > > > > > I think it is data-model specific whether it even possible for > operational > > values to differ from configuration. > > In our core models this is possible for pretty much every parameter that > has any meaning outside NETCONF. > > I doubt that. A new operation like (that you and Martin proposed many IETFs ago) could be defined that provided retrieval of the operational value for config=true nodes. Andy > > > > > > Neither NETCONF or RESTCONF has any charter to edit operational state. > > > This is not something YANG 1.1 can or should add to a protocol. > > > > > > The problem needs to be clarified. What is broken? > > > > Example: > > > > container top { > > leaf foo { ... } > > leaf bar { config false; ... } > > } > > > > Now, if the operational value of "foo" is not the same as the configured > value, a reply to will contain the *configured* value of "foo" and > the real operational value of "bar". IMO, this is broken. > > > > > > But NETCONF and YANG do not claim that "foo" represents anything other > than the > > configured value. A new protocol operation could be somehow inform the > client > > of this situation, but that doesn't change YANG. > > Yes, I thought get2 was intended to allow this but now after reading the > I-D again it doesn't seem to be the case - even with "operational" source, > it will return only "config false" data. > > > > > > > The solution in some of the core modules is to separate the trees > (interfaces and interfaces-state), so at least this could be formulated as > a guideline, but I can also imagine other changes that are compatible with > YANG 1.1 restrictions. > > > > > > Yes -- when the data model designers know the operational values > > can be different, this is the traditional approach. Not sure > > why it is broken. > > The idea of mixing config with state data is IMO broken. > > > > > > > > It seems the problem stated here is an inability to identify > > > operational values different from configuration values? > > > This is supported by using separate objects (oper/admin-status > > > or interface/interface-state). > > > > > > If and when the I2RS WG decides to use RESTCONF or NETCONF > > > for editing operational state, then the requirements will need to be > understood > > > and changes can be made, at that time. > > > > This is not directly related to I2RS, although I2RS could benefit from a > general solution of this issue. > > > > > > It would help to have specific solutions that maintain > backward-compatibility > > with the YANG 1.0 config-stmt. > > > > I agree that an operational datastore is a good way to define new a > > non-persistent edit target, with its own validation rules. But this is > > something to be designed in the protocol and supported in YANG, > > not the other way around. > > Well, I think there has to be *the* operational state datastore that's > used by all management interfaces. Is there any reliable solution for SNMP > competing with NETCONF? > > Lada > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > Andy > > > > > > > > > On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka > wrote: > > > * a better model for configuration versus state data is needed > > > > > > ** Description > > > > > > In YANG 1.0, the distinction between configuration and state data is > > > based on the value of the boolean "config" property. State data > > > (config false) may be embedded within configuration but not vice > > > versa. > > > > > > Whilst this model may be useful for closed devices with tightly > > > controlled configuration interfaces, it is not satifactory for open > > > systems in which NETCONF and/or RESTCONF may not have exclusive > > > control over configurable operational parameters. > > > > > > In such an open system, the design of a data model must take into > > > account that operationally used values may be different from those > > > that appear in NETCONF/RESTCONF configuration datastores - because > > > they may have been changed through other management interfaces or > > > mechanisms. In such a situation, it makes no sense to bundle > > > operational state data such as statistics with NETCONF config data > > > that are not operationally used. > > > > > > Due to the backward compatibility rules for YANG 1.1, it may be > > > impossible to enforce a new config/state-data model, but nevertheless > > > the new model may be formulated as a recommendation, e.g. in 6087bis. > > > > > > ** Solution > > > > > > This is not a complete solution but only a suggestion of principles on > > > which a solution could be based: > > > > > > - A separate (conceptual) datastore containing state data, > > > i.e. parameters that are really used by the device is needed. No > > > management interface will be allowed to lock the state datastore. > > > - Every management interface (which includes NETCONF and > > > RESTCONF) will specify the set of writable parameters, > > > i.e. parameters that may be modified through that management > interface. > > > Some data, such as statistics, may be "absolutely read-only". > > > - Every management interface specifies a particular discipline and > > > workflow for eventual modifications of state data. For NETCONF this > > > means the well-known framework of configurations datastores, > > > commits, locks etc. > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1134f2beb8dae504f6c8e3bd Content-Type: text/html; charset=ISO-8859-1



    On Fri, Apr 11, 2014 at 10:03 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

    On 11 Apr 2014, at 18:35, Andy Bierman <andy@yumaworks.com> wrote:

    >
    >
    >
    > On Fri, Apr 11, 2014 at 9:20 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
    >
    > On 11 Apr 2014, at 17:29, Andy Bierman <andy@yumaworks.com> wrote:
    >
    > > Hi,
    > >
    > > I don't think open vs. closed system has anything to do with this issue.
    >
    > Closed systems that control all user access to a device usually try to make sure that the configured value in fact is the state value.
    >
    > On a normal Linux system that runs NETCONF, the user can change operational state by other means, e.g. via shell utilities, direct writes to /proc, or SNMP.
    >
    >
    > I think it is data-model specific whether it even possible for operational
    > values to differ from configuration.

    In our core models this is possible for pretty much every parameter that has any meaning outside NETCONF.


    I doubt that.
    A new operation like <get-operational> (that you and Martin proposed
    many IETFs ago) could be defined that provided retrieval of the operational value
    for config=true nodes.



    Andy


    >
    >
    > > Neither NETCONF or RESTCONF has any charter to edit operational state.
    > > This is not something YANG 1.1 can or should add to a protocol.
    > >
    > > The problem needs to be clarified.  What is broken?
    >
    > Example:
    >
    > container top {
    >   leaf foo { … }
    >   leaf bar { config false; … }
    > }
    >
    > Now, if the operational value of “foo” is not the same as the configured value, a reply to <get> will contain the *configured* value of “foo” and the real operational value of “bar”. IMO, this is broken.
    >
    >
    > But NETCONF and YANG do not claim that "foo" represents anything other than the
    > configured value.  A new protocol operation could be somehow inform the client
    > of this situation, but that doesn't change YANG.

    Yes, I thought get2 was intended to allow this but now after reading the I-D again it doesn’t seem to be the case - even with “operational” source, it will return only "config false" data.

    >
    >
    > The solution in some of the core modules is to separate the trees (interfaces and interfaces-state), so at least this could be formulated as a guideline, but I can also imagine other changes that are compatible with YANG 1.1 restrictions.
    >
    >
    > Yes -- when the data model designers know the operational values
    > can be different, this is the traditional approach.  Not sure
    > why it is broken.

    The idea of mixing config with state data is IMO broken.

    >
    >
    > > It seems the problem stated here is an inability to identify
    > > operational values different from configuration values?
    > > This is supported by using separate objects (oper/admin-status
    > > or interface/interface-state).
    > >
    > > If and when the I2RS WG decides to use RESTCONF or NETCONF
    > > for editing operational state, then the requirements will need to be understood
    > > and changes can be made, at that time.
    >
    > This is not directly related to I2RS, although I2RS could benefit from a general solution of this issue.
    >
    >
    > It would help to have specific solutions that maintain backward-compatibility
    > with the YANG 1.0 config-stmt.
    >
    > I agree that an operational datastore is a good way to define new a
    > non-persistent edit target, with its own validation rules. But this is
    > something to be designed in the protocol and supported in YANG,
    > not the other way around.

    Well, I think there has to be *the* operational state datastore that’s used by all management interfaces. Is there any reliable solution for SNMP competing with NETCONF?

    Lada

    >
    >
    > Lada
    >
    >
    > Andy
    >
    >
    > >
    > >
    > > Andy
    > >
    > >
    > > On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
    > > * a better model for configuration versus state data is needed
    > >
    > > ** Description
    > >
    > > In YANG 1.0, the distinction between configuration and state data is
    > > based on the value of the boolean "config" property. State data
    > > (config false) may be embedded within configuration but not vice
    > > versa.
    > >
    > > Whilst this model may be useful for closed devices with tightly
    > > controlled configuration interfaces, it is not satifactory for open
    > > systems in which NETCONF and/or RESTCONF may not have exclusive
    > > control over configurable operational parameters.
    > >
    > > In such an open system, the design of a data model must take into
    > > account that operationally used values may be different from those
    > > that appear in NETCONF/RESTCONF configuration datastores - because
    > > they may have been changed through other management interfaces or
    > > mechanisms. In such a situation, it makes no sense to bundle
    > > operational state data such as statistics with NETCONF config data
    > > that are not operationally used.
    > >
    > > Due to the backward compatibility rules for YANG 1.1, it may be
    > > impossible to enforce a new config/state-data model, but nevertheless
    > > the new model may be formulated as a recommendation, e.g. in 6087bis.
    > >
    > > ** Solution
    > >
    > > This is not a complete solution but only a suggestion of principles on
    > > which a solution could be based:
    > >
    > > - A separate (conceptual) datastore containing state data,
    > >   i.e. parameters that are really used by the device is needed. No
    > >   management interface will be allowed to lock the state datastore.
    > > - Every management interface (which includes NETCONF and
    > >   RESTCONF) will specify the set of writable parameters,
    > >   i.e. parameters that may be modified through that management interface.
    > >   Some data, such as statistics, may be "absolutely read-only".
    > > - Every management interface specifies a particular discipline and
    > >   workflow for eventual modifications of state data. For NETCONF this
    > >   means the well-known framework of configurations datastores,
    > >   commits, locks etc.
    > >
    > > --
    > > Ladislav Lhotka, CZ.NIC Labs
    > > PGP Key ID: E74E8C0C
    > >
    > > _______________________________________________
    > > netmod mailing list
    > > netmod@ietf.org
    > > https://www.ietf.org/mailman/listinfo/netmod
    > >
    >
    > --
    > Ladislav Lhotka, CZ.NIC Labs
    > PGP Key ID: E74E8C0C

    --
    Ladislav Lhotka, CZ.NIC Labs
    PGP Key ID: E74E8C0C





    --001a1134f2beb8dae504f6c8e3bd-- From nobody Fri Apr 11 11:59:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7481A02FD for ; Fri, 11 Apr 2014 11:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86UVLmgqMMBE for ; Fri, 11 Apr 2014 11:59:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADBB1A030A for ; Fri, 11 Apr 2014 11:59:44 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B6E3A13F9DD; Fri, 11 Apr 2014 20:59:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397242782; bh=15aiC6+wbGBtXTqPGz1KaLkSCRtkky6B+fpZRfZkTOM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d0SqBybjzN/Mbegh9xw3x+eZkoXMURPki942f2XO0T4KBIvbhd5eEYnDcfgLwmWsy ve3ACFOcT9bWVdQBdlCCFzpGkit9I4MkmCSYrq3V7/qcUmyWHyhId/dJavu5ng9EmT oYfpGSqPqr1ZasaVfSKMIAmfNp2xXwvmqmOfatGE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <69078.1397241259134.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Fri, 11 Apr 2014 20:59:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <360703F4-5D88-47CC-BE33-E1BCDFFC92FB@nic.cz> References: <69078.1397241259134.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> To: Randy Presuhn X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XK8bk4wnJZ4Vw6wZmKqefbroY7w Cc: netmod@ietf.org Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:59:49 -0000 Hi Randy, On 11 Apr 2014, at 20:34, Randy Presuhn = wrote: > Hi - >=20 >> From: Ladislav Lhotka >> Sent: Apr 11, 2014 10:03 AM >> To: Andy Bierman >> Cc: "netmod@ietf.org" >> Subject: Re: [netmod] new issue: configuration versus state data > ... >> Well, I think there has to be *the* operational state datastore >> that=92s used by all management interfaces. > ... >=20 > At the bottom of the pile, on most systems there is. The > problems are that: >=20 > (1) the nature of this datastore may actually be different > for different resources on the same system >=20 > (2) the relationship between this datastore and > data/information models mapped onto it is (to varying > degrees) both model- and implementation-specific >=20 > (3) the various models mapped onto the datastore > sometimes impose conflicting requirements, and > the various sets of instrumentation accessing the > datastore often ignore each other's needs I agree the concept of state datastore is not completely straightforward = but - it is even worse to assume that it is a super-tree of the = configuration tree, - a hierarchical data structure seems to be quite common - YANG, MIB, = /proc, most CLIs. =20 Lada >=20 > It would be lovely to have a way of formally expressing the > relationships for a given system with a particular configuration > (since the relationships depend on the exact combination of > hardware and software and their configuration), so that the > behaviour of that system might be rigorously described. >=20 > But I suspect the reality would turn out to be that for too > many "open" systems, the formal description would only tell you > that the system's behaviour either not fully deterministic, > or that the inter-relationships are so complicated that the > formal description is unhelpful. >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 11 12:01:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CED1A01F3 for ; Fri, 11 Apr 2014 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxlQ4Lc9Pme3 for ; Fri, 11 Apr 2014 12:01: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 3E9C91A02C2 for ; Fri, 11 Apr 2014 12:01:44 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5588113F9DD; Fri, 11 Apr 2014 21:01:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397242902; bh=fBC1WRg86lE4le4YaVCA8Qq2aDqeiRgqNzL4ESlCZVM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eCDPT5oAEOIbcOk/K0qH5LnSUVFsiFZxo0yZ2U8XMfnXE2OOKjdaxBE7pbzRV/7bX CJSjr8JZ5Wp8PbGxycW31qZvq9Pm+zKfBZWXSjrdEY6EoSJTdugVHvdkZmp9s4aXyb NbMHR2iZhOEVQ20Ke7I6Y+gv8MnZuGosVKBTvp8Y= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 11 Apr 2014 21:01:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <25931F95-BE90-4170-8252-A94A44B4A5A2@nic.cz> References: <1D29E6CE-92E7-4A12-93C2-2451CDB1A7FD@nic.cz> <0121D70E-3732-4966-8F47-138AAB6D007E@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KWkwY8o4yGAyBrKGAXI_8dZY6NM Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:01:48 -0000 On 11 Apr 2014, at 20:56, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Apr 11, 2014 at 10:03 AM, Ladislav Lhotka = wrote: >=20 > On 11 Apr 2014, at 18:35, Andy Bierman wrote: >=20 > > > > > > > > On Fri, Apr 11, 2014 at 9:20 AM, Ladislav Lhotka = wrote: > > > > On 11 Apr 2014, at 17:29, Andy Bierman wrote: > > > > > Hi, > > > > > > I don't think open vs. closed system has anything to do with this = issue. > > > > Closed systems that control all user access to a device usually try = to make sure that the configured value in fact is the state value. > > > > On a normal Linux system that runs NETCONF, the user can change = operational state by other means, e.g. via shell utilities, direct = writes to /proc, or SNMP. > > > > > > I think it is data-model specific whether it even possible for = operational > > values to differ from configuration. >=20 > In our core models this is possible for pretty much every parameter = that has any meaning outside NETCONF. >=20 >=20 > I doubt that. > A new operation like (that you and Martin proposed > many IETFs ago) could be defined that provided retrieval of the = operational value > for config=3Dtrue nodes. Yes, there we tried to define the state datastore but I wasn=92t very = happy with the result. Lada =20 >=20 >=20 >=20 > Andy >=20 >=20 > > > > > > > Neither NETCONF or RESTCONF has any charter to edit operational = state. > > > This is not something YANG 1.1 can or should add to a protocol. > > > > > > The problem needs to be clarified. What is broken? > > > > Example: > > > > container top { > > leaf foo { =85 } > > leaf bar { config false; =85 } > > } > > > > Now, if the operational value of =93foo=94 is not the same as the = configured value, a reply to will contain the *configured* value = of =93foo=94 and the real operational value of =93bar=94. IMO, this is = broken. > > > > > > But NETCONF and YANG do not claim that "foo" represents anything = other than the > > configured value. A new protocol operation could be somehow inform = the client > > of this situation, but that doesn't change YANG. >=20 > Yes, I thought get2 was intended to allow this but now after reading = the I-D again it doesn=92t seem to be the case - even with =93operational=94= source, it will return only "config false" data. >=20 > > > > > > The solution in some of the core modules is to separate the trees = (interfaces and interfaces-state), so at least this could be formulated = as a guideline, but I can also imagine other changes that are compatible = with YANG 1.1 restrictions. > > > > > > Yes -- when the data model designers know the operational values > > can be different, this is the traditional approach. Not sure > > why it is broken. >=20 > The idea of mixing config with state data is IMO broken. >=20 > > > > > > > It seems the problem stated here is an inability to identify > > > operational values different from configuration values? > > > This is supported by using separate objects (oper/admin-status > > > or interface/interface-state). > > > > > > If and when the I2RS WG decides to use RESTCONF or NETCONF > > > for editing operational state, then the requirements will need to = be understood > > > and changes can be made, at that time. > > > > This is not directly related to I2RS, although I2RS could benefit = from a general solution of this issue. > > > > > > It would help to have specific solutions that maintain = backward-compatibility > > with the YANG 1.0 config-stmt. > > > > I agree that an operational datastore is a good way to define new a > > non-persistent edit target, with its own validation rules. But this = is > > something to be designed in the protocol and supported in YANG, > > not the other way around. >=20 > Well, I think there has to be *the* operational state datastore that=92s= used by all management interfaces. Is there any reliable solution for = SNMP competing with NETCONF? >=20 > Lada >=20 > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > Andy > > > > > > > > > On Fri, Apr 11, 2014 at 6:40 AM, Ladislav Lhotka = wrote: > > > * a better model for configuration versus state data is needed > > > > > > ** Description > > > > > > In YANG 1.0, the distinction between configuration and state data = is > > > based on the value of the boolean "config" property. State data > > > (config false) may be embedded within configuration but not vice > > > versa. > > > > > > Whilst this model may be useful for closed devices with tightly > > > controlled configuration interfaces, it is not satifactory for = open > > > systems in which NETCONF and/or RESTCONF may not have exclusive > > > control over configurable operational parameters. > > > > > > In such an open system, the design of a data model must take into > > > account that operationally used values may be different from those > > > that appear in NETCONF/RESTCONF configuration datastores - because > > > they may have been changed through other management interfaces or > > > mechanisms. In such a situation, it makes no sense to bundle > > > operational state data such as statistics with NETCONF config data > > > that are not operationally used. > > > > > > Due to the backward compatibility rules for YANG 1.1, it may be > > > impossible to enforce a new config/state-data model, but = nevertheless > > > the new model may be formulated as a recommendation, e.g. in = 6087bis. > > > > > > ** Solution > > > > > > This is not a complete solution but only a suggestion of = principles on > > > which a solution could be based: > > > > > > - A separate (conceptual) datastore containing state data, > > > i.e. parameters that are really used by the device is needed. No > > > management interface will be allowed to lock the state = datastore. > > > - Every management interface (which includes NETCONF and > > > RESTCONF) will specify the set of writable parameters, > > > i.e. parameters that may be modified through that management = interface. > > > Some data, such as statistics, may be "absolutely read-only". > > > - Every management interface specifies a particular discipline and > > > workflow for eventual modifications of state data. For NETCONF = this > > > means the well-known framework of configurations datastores, > > > commits, locks etc. > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 11 13:07:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295B81A033B for ; Fri, 11 Apr 2014 13:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXAgO_aXJVHc for ; Fri, 11 Apr 2014 13:07:37 -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 32A151A022E for ; Fri, 11 Apr 2014 13:07:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KxlZZnQhjbCQZ4nrgzJ892DJxqXiy5yrkLPZnmYkPDGzYXEACtwFQZe5Eot48jEu; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WYhjb-00054K-8s for netmod@ietf.org; Fri, 11 Apr 2014 16:07:35 -0400 Received: from 99.101.142.107 by webmail.earthlink.net with HTTP; Fri, 11 Apr 2014 16:07:34 -0400 Message-ID: <11909938.1397246854984.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Fri, 11 Apr 2014 13:07:34 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbcae606814798c59d13acc8721a17b20ce350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/852GL92fWTF9aGzXKr7a3AVFDj4 Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:07:42 -0000 Hi - >From: Ladislav Lhotka >Sent: Apr 11, 2014 11:59 AM >To: Randy Presuhn >Cc: netmod@ietf.org >Subject: Re: [netmod] new issue: configuration versus state data ... >I agree the concept of state datastore is not completely straightforward but > >- it is even worse to assume that it is a super-tree of the configuration tree, > >- a hierarchical data structure seems to be quite common - YANG, MIB, /proc, most CLIs. ... It's an annoyance, but I don't see that aspect of the problem as being substantially different from what is faced by the (sub)agent developer for any other protocol: one must realistically start with the assumption that the interoperable model will differ from managed resource's native representation. Sometimes a little, sometimes a lot. If you're lucky, those differences will be mostly just how the bits and pieces are identified and organized; those mappings are easily dealt with in code-generating tools with the help of developer-provided hints. Systematic mappings between data types are also tractable. Where it gets messy (as in some of the cases you alluded to) is when there are real differences in the semantics (including side-effects) of multiple models/protocols accessing what should be the same underlying information. I guess it depends on what one's expectations / vision for netconf-based management are. If one is just looking for a way to deliver more-or-less proprietary blobs of configuration data, the expectations will be considerably less demanding than those of someone looking for a full-blown management protocol or an actual configuration management tool. Part of what it sounds like you're asking for is a better integration between the protocol and the yang meta-model. The difficulty is that the latter doesn't seem to have been worked out, and I'm sure some folks would say that this is by design, and a feature rather than a bug. Randy From nobody Fri Apr 11 14:26:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB371A0767; Fri, 11 Apr 2014 14:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AshVnDg7Nr3R; Fri, 11 Apr 2014 14:26:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CDF1A0766; Fri, 11 Apr 2014 14:26:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411212639.22884.54072.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 14:26:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2M_ILXaGKJac9uLMr9Zqxi3zHxY Cc: netmod WG Subject: [netmod] WG Action: Rechartered NETCONF Data Modeling Language (netmod) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:26:44 -0000 The NETCONF Data Modeling Language (netmod) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. NETCONF Data Modeling Language (netmod) ------------------------------------------------ Current Status: Active WG Chairs: Jürgen Schönwälder Tom Nadeau Assigned Area Director: Benoit Claise Mailing list Address: netmod@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netmod Archive: http://www.ietf.org/mail-archive/web/netmod/ Charter: The NETMOD working group has defined the data modeling language YANG, which can be used to specify network management data models that are manipulated by the NETCONF protocol. The NETMOD working group also defined a number of core data models as basic building blocks. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by maintaining and evolving the core YANG specifications based on usage experience. The NETMOD WG may also develop any additional data models written in YANG that the WG considers core building blocks and that do not fall under the charters of other active IETF working groups. The NETMOD WG may simply add such milestones as it sees fit, with the advice and consent of the responsible AD. The NETMOD Working Group will produce a maintenance release of the core YANG specification called YANG 1.1, that is a revision of RFC 6020. The changes to RFC 6020 are restricted in the following ways: - All compliant YANG 1.0 modules must be accepted as compliant YANG 1.1 modules. - All known ambiguities of YANG 1.0 and all reported defects and errata will be addressed. - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. - The changes of the specification will be kept to the minimum necessary to achieve the previously stated goals. The NETMOD Working Group will also revise the Guidelines for Authors and Reviewers of YANG Data Models (RFC 6087) in order to fix any ambiguities and to incorporate the lessons learned by producing YANG data models. The NETMOD Working Group will produce a specification how YANG-defined data trees can be represented in JSON. The NETMOD Working Group will not serve as a review team for YANG modules developed by other working groups. The YANG doctors, organized by the OPS area director responsible for network management, can act as advisors for other working groups and they provide YANG reviews for the OPS area directors [1]. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with work in NETCONF. [1] http://www.ietf.org/iesg/directorate/yang-doctors.html Milestones: Apr 2014 - Submit first working group draft of the stateless packet filter data model Apr 2014 - Submit first working group draft of a mapping to JSON May 2014 - Compiled issue list to be considered for YANG 1.1 Jul 2014 - Submit first working group draft of YANG 1.1 Oct 2014 - Submit stateless packet filter data model to the IESG Oct 2014 - Submit the mapping to JSON to the IESG Mar 2015 - Submit YANG 1.1 to the IESG From nobody Fri Apr 11 14:48:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B9F1A035F for ; Fri, 11 Apr 2014 14:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSvdQXw95dtc for ; Fri, 11 Apr 2014 14:48:16 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id A6A061A034A for ; Fri, 11 Apr 2014 14:48:16 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id cm18so4934744qab.4 for ; Fri, 11 Apr 2014 14:48:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1JWbKFbQ5YA7na/6JQ+Z4UuI03XS6IZWObgaWcLwVS8=; b=SoekUgirNdlb3B+qRfFm5VlodsWXKJ227f64u2YIGTJwVfchfVuj2eQ6uTkYy8IZzG 8RaO+P8T9nkNDWAvPpRt7YvRpisV3CSHdvcjqms8PQ5EUydHSZ+O3+/i6hQA6LUYd68f WodpX5r50x6Z4uKQXTYFpMk11Pa9W0XECZrRd98T4ESLhXVD9OYAd5NMuTdMJUxx3Yjf QNtnevXHKo8JcTd1jVeqxWmqN2ehTVHESQnxYBrjrA1tszwvLsJJHBnrhmT1yuVemqRu 0FWgW9KVjpwLENjTDS6jlN49bHtcPU1+jAiAGnAkwkcBhGNDVb2HqbSaLucBdJDS5YxV 17ng== X-Gm-Message-State: ALoCoQn37YwThgdmpGmh7tbr/tUFG33bjSS16hBmTfqwThKEMfJAwd1eH8YRGoeGQ0Az8efYQyAZ MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr30849846qgo.25.1397252895016; Fri, 11 Apr 2014 14:48:15 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 11 Apr 2014 14:48:14 -0700 (PDT) In-Reply-To: <11909938.1397246854984.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> References: <11909938.1397246854984.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Fri, 11 Apr 2014 14:48:14 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a11c15fa67820ac04f6cb4a2a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xk7P2afVgwaYM1vShPrvLXrYpN8 Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:48:18 -0000 --001a11c15fa67820ac04f6cb4a2a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 11, 2014 at 1:07 PM, Randy Presuhn wrote: > Hi - > > >From: Ladislav Lhotka > >Sent: Apr 11, 2014 11:59 AM > >To: Randy Presuhn > >Cc: netmod@ietf.org > >Subject: Re: [netmod] new issue: configuration versus state data > ... > >I agree the concept of state datastore is not completely straightforward > but > > > >- it is even worse to assume that it is a super-tree of the configuration > tree, > > > >- a hierarchical data structure seems to be quite common - YANG, MIB, > /proc, most CLIs. > ... > > It's an annoyance, but I don't see that aspect of the problem as > being substantially different from what is faced by the (sub)agent > developer for any other protocol: one must realistically start with > the assumption that the interoperable model will differ from managed > resource's native representation. Sometimes a little, sometimes a lot. > > If you're lucky, those differences will be mostly just how the bits > and pieces are identified and organized; those mappings are easily > dealt with in code-generating tools with the help of developer-provided > hints. Systematic mappings between data types are also tractable. > Where it gets messy (as in some of the cases you alluded to) is when > there are real differences in the semantics (including side-effects) > of multiple models/protocols accessing what should be the same > underlying information. > > I guess it depends on what one's expectations / vision for > netconf-based management are. If one is just looking for a > way to deliver more-or-less proprietary blobs of configuration > data, the expectations will be considerably less demanding > than those of someone looking for a full-blown management > protocol or an actual configuration management tool. > > Getting vendors to agree on standard configuration will take time. There will always be a mix of standard and vendor modules, just like with SNMP/SMIv2. > Part of what it sounds like you're asking for is a better > integration between the protocol and the yang meta-model. > The difficulty is that the latter doesn't seem to have been > worked out, and I'm sure some folks would say that this > is by design, and a feature rather than a bug. > > There are many aspects of network operations that are left to vendor implementation. So what? Commercial engineering can be more messy than it should be (as envisioned by the computer scientists who don't have to get the code done ASAP. ;;) > Randy > Andy --001a11c15fa67820ac04f6cb4a2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Fri, Apr 11, 2014 at 1:07 PM, Randy Presuhn &l= t;randy_p= resuhn@mindspring.com> wrote:
    Hi -

    >From: Ladislav Lhotka <lhotka@nic.c= z>
    >Sent: Apr 11, 2014 11:59 AM
    >To: Randy Presuhn <r= andy_presuhn@mindspring.com>
    >Cc: netmod@ietf.org
    >Subject: Re: [netmod] new issue: configuration versus state data
    ...
    >I agree the concept of state datastore is not completely straightforwar= d but
    >
    >- it is even worse to assume that it is a super-tree of the configurati= on tree,
    >
    >- a hierarchical data structure seems to be quite common - YANG, MIB, /= proc, most CLIs.
    ...

    It's an annoyance, but I don't see that aspect of the problem as being substantially different from what is faced by the (sub)agent
    developer for any other protocol: one must realistically start with
    the assumption that the interoperable model will differ from managed
    resource's native representation. Sometimes a little, sometimes a lot.<= br>
    If you're lucky, those differences will be mostly just how the bits
    and pieces are identified and organized; those mappings are easily
    dealt with in code-generating tools with the help of developer-provided
    hints. =A0Systematic mappings between data types are also tractable.
    Where it gets messy (as in some of the cases you alluded to) is when
    there are real differences in the semantics (including side-effects)
    of multiple models/protocols accessing what should be the same
    underlying information.

    I guess it depends on what one's expectations / vision for
    netconf-based management are. =A0If one is just looking for a
    way to deliver more-or-less proprietary blobs of configuration
    data, the expectations will be considerably less demanding
    than those of someone looking for a full-blown management
    protocol or an actual configuration management tool.



    Getting vendors to agre= e on standard configuration will take time.
    There will always be = a mix of standard and vendor modules,
    just like with SNMP/SMIv2.<= /div>


    =A0
    Part of what it sounds like you're asking for is a better
    integration between the protocol and the yang meta-model.
    The difficulty is that the latter doesn't seem to have been
    worked out, and I'm sure some folks would say that this
    is by design, and a feature rather than a bug.


    There are many aspects of network oper= ations that are left to
    vendor implementation. =A0So what? Commer= cial engineering can be
    more messy than it should be (as envision= ed by the computer
    scientists who don't have to get the code done ASAP. ;;)

    =A0
    Randy

    Andy

    --001a11c15fa67820ac04f6cb4a2a-- From nobody Fri Apr 11 15:43:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57461A01EC for ; Fri, 11 Apr 2014 15:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7hHvA6kesnn for ; Fri, 11 Apr 2014 15:43:27 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 670591A0214 for ; Fri, 11 Apr 2014 15:43:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UbW7CvVKP/ny/nIykgqOhQbZ/3B8EcJTjfhaAkYHyBxIv39xAYqnAU0FAlpBNUqc; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WYkAP-0003oU-Al for netmod@ietf.org; Fri, 11 Apr 2014 18:43:25 -0400 Received: from 99.101.142.107 by webmail.earthlink.net with HTTP; Fri, 11 Apr 2014 18:43:25 -0400 Message-ID: <14362561.1397256205285.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Fri, 11 Apr 2014 15:43:25 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbcbe3d359265b7f7b96cc1d496ba1152ef350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TRFxdfkGabZRTPSg9dZIiTa5S3M Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 22:43:32 -0000 Hi - >From: Andy Bierman >Sent: Apr 11, 2014 2:48 PM >To: Randy Presuhn >Cc: "netmod@ietf.org" >Subject: Re: [netmod] new issue: configuration versus state data ... >There are many aspects of network operations that are left to >vendor implementation. So what? Commercial engineering can be >more messy than it should be (as envisioned by the computer >scientists who don't have to get the code done ASAP. ;;) The engineering question is finding the sweet spot(s) where there is sufficient commonality between models to balance the operational costs of diversity with the perceived development cost savings of quick-and-dirty implementation and the integration costs (within open and multi-vendor systems) of creating "weird plumbing adapters", especially when faced with the reality of multiple configuration interfaces. In my opinion a long-standing shortcoming of the network management community has been its tendency to give undue weight to the goal of minimizing constraints on implementations, while neglecting the very real system integration and operations costs that come as a consequence. There are times when "let a thousand flowers bloom" can spur innovation and benefit vendors, but there are times when it turns out like "the great leap forward" from a user / customer perspective. I'm not arguing "thou shalt use only standard models". Rather, I'm claiming that to be operationally helpful in diverse environments, there needs to be a sufficiently strong metamodel underneath it all to permit basic generic processing of all resources, whether standard or propriety. Deciding just how sophisticated "basic generic processing" is, and consequently how much commonality is enough, is an engineering tradeoff, but these nagging problems suggest to me that the bar was set too low. Randy From nobody Sun Apr 13 11:07:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EB21A020F for ; Sun, 13 Apr 2014 11:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbgRopawUmqt for ; Sun, 13 Apr 2014 11:07:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E11A0204 for ; Sun, 13 Apr 2014 11:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3000; q=dns/txt; s=iport; t=1397412423; x=1398622023; h=from:to:subject:date:message-id:mime-version; bh=3jqU0Ge1zJtAyjCImrYsphd5f2PJe5V8Qm6UUJa5J9M=; b=BfY0qXq5MMvXLg2g/9ARZI1aawqEy51d4JXJ3qIAQcfzUjziD1CLpf06 DqQmP7QSBJuqok6cjlMpTy457u5YOO8T3mIbPNamUrH7sWjyREz2YZUO3 fWLbR9f+c9d9vJc5xB9G8an3nOAmmNf6MHshqqCP5tmowZB5ypfAfVFNe U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAF3RSlOtJA2I/2dsb2JhbABZgkJEO1fDLoEbFnSCJwEELV4BDB5WJgEEG4d0mRWxOheOPYNcgRQEqySDMYFrJBw X-IronPort-AV: E=Sophos;i="4.97,852,1389744000"; d="scan'208,217";a="317413170" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 13 Apr 2014 18:07:02 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3DI7271029770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 13 Apr 2014 18:07:02 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.83]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 13 Apr 2014 13:07:02 -0500 From: "Tissa Senevirathne (tsenevir)" To: "netmod@ietf.org" Thread-Topic: tool to check XPath in YANG ? Thread-Index: Ac9XQyonnYu6ZqlSTjygy7Uo3Ei0Og== Date: Sun, 13 Apr 2014 18:07:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.76] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD6E1xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_2cKB_bLPOqIjK23iJsM2yWu0p4 Subject: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 18:07:06 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD6E1xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am using pyang with --lax-xpath-checks to validate the XPath information.= However for when and must key word it does only basic syntax validations. Does anyone know a tool that I can use to validate the complete range of XP= ath within YANG. (including when and must) Thanks in advance Tissa --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD6E1xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I am using pyang with --lax-xpath-checks to validate= the XPath information. However for when and must key word it does only bas= ic syntax validations.

     

    Does anyone know a tool that I can use to validate t= he complete range of XPath within YANG. (including when and must)

     

    Thanks in advance

    Tissa

    --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD6E1xmbrcdx08ciscoc_-- From nobody Sun Apr 13 12:05:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1476A1A0218 for ; Sun, 13 Apr 2014 12:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y66oWcjReyes for ; Sun, 13 Apr 2014 12:05:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 815791A02D2 for ; Sun, 13 Apr 2014 12:05:41 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8AD4913F9B1; Sun, 13 Apr 2014 21:05:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397415938; bh=Ezho7tdhQaWAVmpZFsjq9Hn3M7PuvbqXu8l7YKYpcHw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tj81kyt0JxQo9s3aEQOmBG62mb1tY6sN96XBMT5XsNWRApcM8QvIslYI0EFXFCf/q MXRCH4LDUOXNBSvfz2VPfzR4IwevOfRInhdoh7y9+ULQ+R80nx2Xipcn+fWCswbPTj MygdpAlM+uQmwnXQzVD4tBOJGL2ULzxutUDU0fbw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 13 Apr 2014 21:05:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Tissa Senevirathne (tsenevir)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mB7qPaCXEvcu9Zg9_82zBO6TuJQ Cc: "netmod@ietf.org" Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 19:05:43 -0000 Hi Tissa, On 13 Apr 2014, at 20:07, Tissa Senevirathne (tsenevir) = wrote: > I am using pyang with --lax-xpath-checks to validate the XPath = information. However for when and must key word it does only basic = syntax validations. > =20 > Does anyone know a tool that I can use to validate the complete range = of XPath within YANG. (including when and must) What exactly do you want to validate? Correctness of YANG modules, or = validity of XML instance data with respect to =93must=94 or =93when=94 = constraints? Lada > =20 > Thanks in advance > Tissa > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Apr 13 12:10:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A401A02CA for ; Sun, 13 Apr 2014 12:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKY-R6eNBfBw for ; Sun, 13 Apr 2014 12:10:27 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 970721A0258 for ; Sun, 13 Apr 2014 12:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1288; q=dns/txt; s=iport; t=1397416225; x=1398625825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8NtRmYhafCAJrZ/+YCxK86m1bVEytPM79EjqNu4CaeM=; b=An9x6YCO5mxew01jew17nCiMWBFfknjxCKT10moHPjXelRljDLlAI/Vo mK6XvSGacIXzozunOxr1lq8CfrHhxxmDPLGmPEnLTW010dtmi2w0jmOyC ZcNV3Ql5NqhMBgTvVxMkTnXp3YlDSlfERsWRUN5jvwnyDs9uj5V+Y8Qk4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAI/gSlOtJA2L/2dsb2JhbABYgwY7V7t5hmRRgRsWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAQEEDgUIh2wIDcpDEwSOPTEHBoMegRQEqySDMYFrJBw X-IronPort-AV: E=Sophos;i="4.97,852,1389744000"; d="scan'208";a="35431858" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 13 Apr 2014 19:10:24 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3DJAOFm030448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Apr 2014 19:10:24 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.83]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Sun, 13 Apr 2014 14:10:23 -0500 From: "Tissa Senevirathne (tsenevir)" To: Ladislav Lhotka Thread-Topic: [netmod] tool to check XPath in YANG ? Thread-Index: Ac9XQyonnYu6ZqlSTjygy7Uo3Ei0OgAMhnMAAApyqOA= Date: Sun, 13 Apr 2014 19:10:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i3xTE8wvZ5fPyi9_ha1sm8b4gOc Cc: "netmod@ietf.org" Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 19:10:29 -0000 Hi Lada I want to validate say for example. When "../../f:foo-1/f:ffoo-2 =3D 'bar' " I could enter the path wrong, how can I check this using a tool or I want to have multiple "or" combinations and want to check for the syn= tax of the XPath statement. -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Sunday, April 13, 2014 12:06 PM To: Tissa Senevirathne (tsenevir) Cc: netmod@ietf.org Subject: Re: [netmod] tool to check XPath in YANG ? Hi Tissa, On 13 Apr 2014, at 20:07, Tissa Senevirathne (tsenevir) wrote: > I am using pyang with --lax-xpath-checks to validate the XPath informatio= n. However for when and must key word it does only basic syntax validations= . > =20 > Does anyone know a tool that I can use to validate the complete range of = XPath within YANG. (including when and must) What exactly do you want to validate? Correctness of YANG modules, or valid= ity of XML instance data with respect to "must" or "when" constraints? Lada > =20 > Thanks in advance > Tissa > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Apr 13 12:32:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C811A02D1 for ; Sun, 13 Apr 2014 12:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zicDWfQ3Z_tX for ; Sun, 13 Apr 2014 12:32:51 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3A11A026B for ; Sun, 13 Apr 2014 12:32:50 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so710850qga.36 for ; Sun, 13 Apr 2014 12:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RdGcohbu4pKvMsxHU1HFRPxn9gPTMiaKxAAC8sm35wg=; b=CXVEct7Uf9W+6/On5/CdcDrgIFkuE817feoUuR5Jv6ZkUCNTu6qW7tC6I0v8Jj5zqP ASV80trPzBCJbe0C+NnV53KH3UQUgKqb5LViCTpnObe4GrOHw+FvQpFuXTyQbEMLXrci +Eat8GwAMdj5BhW/HwO+TzzpzY5BEvclCLKwQBMGTFp7JYlpYh9ZEd3aZmJJ3Xo5R84B KYPHSGTANQ3oq2HmJLXUg8AJFdhHaVv85LlqaOh8YhB8GWLM61P0JQacfWnAV3O2tn18 ugnkUCHQl0WiQdqhIIBsCpt92tJuyKIfLB9mzaDmKJpntGifl15Fy5mcdcDCilp4/YRO x8OQ== X-Gm-Message-State: ALoCoQk7xNHrv06r+UOmJe4zPEdfKtjaRgOtf41+Uhshv72g2kEB94V3AswhG/lfKljvVzfzU8re MIME-Version: 1.0 X-Received: by 10.140.36.77 with SMTP id o71mr42495175qgo.25.1397417568667; Sun, 13 Apr 2014 12:32:48 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sun, 13 Apr 2014 12:32:48 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Apr 2014 12:32:48 -0700 Message-ID: From: Andy Bierman To: "Tissa Senevirathne (tsenevir)" Content-Type: multipart/alternative; boundary=001a11c15fa6c89b0c04f6f1a1dd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-Zub9Y4190QtP8M31bM9Bv0dJIo Cc: "netmod@ietf.org" Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 19:32:52 -0000 --001a11c15fa6c89b0c04f6f1a1dd Content-Type: text/plain; charset=ISO-8859-1 Hi, You could try the yangdump-pro compiler online. It checks must/when XPath path-stmts. http://www.netconfcentral.org/run_yangdump Andy On Sun, Apr 13, 2014 at 12:10 PM, Tissa Senevirathne (tsenevir) < tsenevir@cisco.com> wrote: > Hi Lada > > I want to validate say for example. > > When "../../f:foo-1/f:ffoo-2 = 'bar' " > > I could enter the path wrong, how can I check this using a tool > > or I want to have multiple "or" combinations and want to check for the > syntax of the XPath statement. > > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Sunday, April 13, 2014 12:06 PM > To: Tissa Senevirathne (tsenevir) > Cc: netmod@ietf.org > Subject: Re: [netmod] tool to check XPath in YANG ? > > Hi Tissa, > > On 13 Apr 2014, at 20:07, Tissa Senevirathne (tsenevir) < > tsenevir@cisco.com> wrote: > > > I am using pyang with --lax-xpath-checks to validate the XPath > information. However for when and must key word it does only basic syntax > validations. > > > > Does anyone know a tool that I can use to validate the complete range of > XPath within YANG. (including when and must) > > What exactly do you want to validate? Correctness of YANG modules, or > validity of XML instance data with respect to "must" or "when" constraints? > > Lada > > > > > Thanks in advance > > Tissa > > _______________________________________________ > > 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 > --001a11c15fa6c89b0c04f6f1a1dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    You could try the yangdump-pro comp= iler online.
    It checks must/when XPath path-stmts.

    =
    =A0 =A0ht= tp://www.netconfcentral.org/run_yangdump


    Andy
    On Sun, Apr 13, 2014 at 12:10 PM, Tissa Senevir= athne (tsenevir) <tsenevir@cisco.com> wrote:
    Hi Lada

    I want to validate say for example.

    When "../../f:foo-1/f:ffoo-2 =3D 'bar' "

    I could enter the path wrong, how can I check this using a tool

    =A0or I want to have multiple "or" combinations and want to check= for the syntax of the XPath statement.

    -----Original Message-----
    From: Ladislav Lhotka [mailto:lhotka@nic.c= z]
    Sent: Sunday, April 13, 2014 12:06 PM
    To: Tissa Senevirathne (tsenevir)
    Cc: netmod@ietf.org
    Subject: Re: [netmod] tool to check XPath in YANG ?

    Hi Tissa,

    On 13 Apr 2014, at 20:07, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

    > I am using pyang with --lax-xpath-checks to validate the XPath informa= tion. However for when and must key word it does only basic syntax validati= ons.
    >
    > Does anyone know a tool that I can use to validate the complete range = of XPath within YANG. (including when and must)

    What exactly do you want to validate? Correctness of YANG modules, or valid= ity of XML instance data with respect to "must" or "when&quo= t; constraints?

    Lada

    >
    > Thanks in advance
    > Tissa
    > _______________________________________________
    > 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

    --001a11c15fa6c89b0c04f6f1a1dd-- From nobody Sun Apr 13 12:37:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D59A1A021D for ; Sun, 13 Apr 2014 12:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbRfCaBFKSXP for ; Sun, 13 Apr 2014 12:37:37 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4771A0204 for ; Sun, 13 Apr 2014 12:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8641; q=dns/txt; s=iport; t=1397417855; x=1398627455; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VW3gKldPgphMckHwKnLB3usBpgHFx6rWIk5sdrzs5xI=; b=Xw9SikY3rJKzXti1MWAwxJb4ng/v0eDpvE0O029E0UQ9KC4gsJm+b0o9 uFhoGzx8wsirx+Fk6YLLg5slIIo1hGp/aS+D6MMKSfvZTw8pDcYJAasm6 h9t7trYcJ1x7rKVv4Wn/Q5TBxIp4Sa6s59ovuOUsZZJIOQ38QlbGL43T7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHXmSlOtJV2a/2dsb2JhbABYgkJEO1e7eYZkUYEcFnSCJQEBAQMBAQEBKkELBQcEAgEIEQQBAQsdBycLFAkIAQEEDgUIAYdrCA3KRReOPS0EBgEGgx6BFASrJIMxgWskHA X-IronPort-AV: E=Sophos; i="4.97,852,1389744000"; d="scan'208,217"; a="35426556" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 13 Apr 2014 19:37:34 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3DJbYfZ007985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Apr 2014 19:37:34 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.83]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 13 Apr 2014 14:37:34 -0500 From: "Tissa Senevirathne (tsenevir)" To: Andy Bierman Thread-Topic: [netmod] tool to check XPath in YANG ? Thread-Index: Ac9XQyonnYu6ZqlSTjygy7Uo3Ei0OgAMhnMAAApyqOD//7QBAIAAUs/Q Date: Sun, 13 Apr 2014 19:37:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.76] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD738xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ATJnd6UirSxNtNuQMvyiZnfmcwE Cc: "netmod@ietf.org" Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 19:37:39 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD738xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Andy, it does what I was looking for, From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Sunday, April 13, 2014 12:33 PM To: Tissa Senevirathne (tsenevir) Cc: Ladislav Lhotka; netmod@ietf.org Subject: Re: [netmod] tool to check XPath in YANG ? Hi, You could try the yangdump-pro compiler online. It checks must/when XPath path-stmts. http://www.netconfcentral.org/run_yangdump Andy On Sun, Apr 13, 2014 at 12:10 PM, Tissa Senevirathne (tsenevir) > wrote: Hi Lada I want to validate say for example. When "../../f:foo-1/f:ffoo-2 =3D 'bar' " I could enter the path wrong, how can I check this using a tool or I want to have multiple "or" combinations and want to check for the syn= tax of the XPath statement. -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz] Sent: Sunday, April 13, 2014 12:06 PM To: Tissa Senevirathne (tsenevir) Cc: netmod@ietf.org Subject: Re: [netmod] tool to check XPath in YANG ? Hi Tissa, On 13 Apr 2014, at 20:07, Tissa Senevirathne (tsenevir) > wrote: > I am using pyang with --lax-xpath-checks to validate the XPath informatio= n. However for when and must key word it does only basic syntax validations= . > > Does anyone know a tool that I can use to validate the complete range of = XPath within YANG. (including when and must) What exactly do you want to validate? Correctness of YANG modules, or valid= ity of XML instance data with respect to "must" or "when" constraints? Lada > > Thanks in advance > Tissa > _______________________________________________ > 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 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD738xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Thanks Andy, it does what= I was looking for,

     <= /p>

    From: Andy Bie= rman [mailto:andy@yumaworks.com]
    Sent: Sunday, April 13, 2014 12:33 PM
    To: Tissa Senevirathne (tsenevir)
    Cc: Ladislav Lhotka; netmod@ietf.org
    Subject: Re: [netmod] tool to check XPath in YANG ?

     

    Hi,

     

    You could try the yangdump-pro compiler online.=

    It checks must/when XPath path-stmts.

     

       http://www.netconfcentral.org/run_yangdump



    Andy

     

    On Sun, Apr 13, 2014 at 12:10 PM, Tissa Senevirathne= (tsenevir) <tse= nevir@cisco.com> wrote:

    Hi Lada

    I want to validate say for example.

    When "../../f:foo-1/f:ffoo-2 =3D 'bar' "

    I could enter the path wrong, how can I check this using a tool

     or I want to have multiple "or" combinations and want to ch= eck for the syntax of the XPath statement.

    -----Original Message-----
    From: Ladislav Lhotka [mailto:lhotka@nic.c= z]
    Sent: Sunday, April 13, 2014 12:06 PM
    To: Tissa Senevirathne (tsenevir)
    Cc: netmod@ietf.org
    Subject: Re: [netmod] tool to check XPath in YANG ?

    Hi Tissa,

    On 13 Apr 2014, at 20:07, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

    > I am using pyang with --lax-xpath-checks to validate the XPath informa= tion. However for when and must key word it does only basic syntax validati= ons.
    >
    > Does anyone know a tool that I can use to validate the complete range = of XPath within YANG. (including when and must)

    What exactly do you want to validate? Correctness of YANG modules, or valid= ity of XML instance data with respect to "must" or "when&quo= t; constraints?

    Lada

    >
    > Thanks in advance
    > Tissa
    > _______________________________________________
    > 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

     

    --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFBD738xmbrcdx08ciscoc_-- From nobody Sun Apr 13 23:53:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28381A026F for ; Sun, 13 Apr 2014 23:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DanL92sgN8wi for ; Sun, 13 Apr 2014 23:53:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 14B681A0278 for ; Sun, 13 Apr 2014 23:53:37 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2902A13F678; Mon, 14 Apr 2014 08:53:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397458414; bh=4KFV9TDQ5MWRQQogpNnuE73IT9hWYgdkrDae2F3zyvU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tbZJEDAJTynm2qenjWOGPT8yBU1L4rXxOJvP1KbP6NmYMw+xzRqF6okKs+he8osZk 9Il+m/SFPD6kgVrC32j1ZUc8Gj2i3wca3Yfl+i4ickAG4aIuFUfyP+hdHvZkCrnTri Fy2Dr1ehk2YcljMdKVEW7h1fNFj93SKgpN4fJXlU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 14 Apr 2014 08:53:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Tissa Senevirathne (tsenevir)" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LeZTDhoKEi5sMBnOoY2JJDi0g2k Cc: "netmod@ietf.org" Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 06:53:42 -0000 On 13 Apr 2014, at 21:10, Tissa Senevirathne (tsenevir) = wrote: > Hi Lada >=20 > I want to validate say for example. >=20 > When "../../f:foo-1/f:ffoo-2 =3D 'bar' " >=20 > I could enter the path wrong, how can I check this using a tool >=20 > or I want to have multiple "or" combinations and want to check for the = syntax of the XPath statement. As far as I can tell, pyang does check syntax of XPath expressions. The problem with paths is that they are not a priori wrong, they just = may evaluate to an empty nodeset - and the evaluation can be performed = only in a context of an XML instance document, not at the time the YANG = module is being validated. For example, an XPath expression may refer to = a node that is defined in another module. By the way, --lax-xpath-checks flag results in *weaker* XPath checks, = which is not what you normally want. Lada =20 >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: Sunday, April 13, 2014 12:06 PM > To: Tissa Senevirathne (tsenevir) > Cc: netmod@ietf.org > Subject: Re: [netmod] tool to check XPath in YANG ? >=20 > Hi Tissa, >=20 > On 13 Apr 2014, at 20:07, Tissa Senevirathne (tsenevir) = wrote: >=20 >> I am using pyang with --lax-xpath-checks to validate the XPath = information. However for when and must key word it does only basic = syntax validations. >>=20 >> Does anyone know a tool that I can use to validate the complete range = of XPath within YANG. (including when and must) >=20 > What exactly do you want to validate? Correctness of YANG modules, or = validity of XML instance data with respect to "must" or "when" = constraints? >=20 > Lada >=20 >>=20 >> Thanks in advance >> Tissa >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Apr 13 23:58:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6561A0389 for ; Sun, 13 Apr 2014 23:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpr5uzBbydpO for ; Sun, 13 Apr 2014 23:58:29 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF951A0387 for ; Sun, 13 Apr 2014 23:58:29 -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 7E47739416F; Mon, 14 Apr 2014 08:58:26 +0200 (CEST) Date: Mon, 14 Apr 2014 08:58:26 +0200 (CEST) Message-Id: <20140414.085826.13684214630649317.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m0V1ALZ7X0IjI7raglQPqOOaKqc Cc: netmod@ietf.org Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 06:58:31 -0000 Ladislav Lhotka wrote: > > On 13 Apr 2014, at 21:10, Tissa Senevirathne (tsenevir) > wrote: > > > Hi Lada > > > > I want to validate say for example. > > > > When "../../f:foo-1/f:ffoo-2 = 'bar' " > > > > I could enter the path wrong, how can I check this using a tool > > > > or I want to have multiple "or" combinations and want to check for the > > syntax of the XPath statement. > > As far as I can tell, pyang does check syntax of XPath expressions. Not really, it performs some very trivial syntax checks (runs a scanner) but it doesn't check the grammar. > The problem with paths is that they are not a priori wrong, they just > may evaluate to an empty nodeset - and the evaluation can be performed > only in a context of an XML instance document, not at the time the > YANG module is being validated. For example, an XPath expression may > refer to a node that is defined in another module. +1 ... but the compiler should be able to warn about these situations. /martin From nobody Mon Apr 14 00:15:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14C1A0273 for ; Mon, 14 Apr 2014 00:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XoXWXpPKW5v for ; Mon, 14 Apr 2014 00:14: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 BC5191A0222 for ; Mon, 14 Apr 2014 00:14:55 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D8EB013F678; Mon, 14 Apr 2014 09:14:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397459693; bh=txrnp2nj01WrTel3UDi5ZcO6+CILgFHlySle3sCtebY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EYszL6MIO/lUM0SfG1GhPn7hmayZ91ZUNGaDyb6acKbxdL2nJjTcHFZg/PDZl7/TP TIf3auMj4nYbFD7Xgf4JJbNzw1rjcieBQUF9hjbat1sy/rNh2drUMbY5f1r4vlDqOs f1Ptr2lPxpPlw0HS90OUWSnEiOSl50GuhDE74R8k= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140414.085826.13684214630649317.mbj@tail-f.com> Date: Mon, 14 Apr 2014 09:14:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0697B38E-A297-4352-A38B-8A9B0E4182C9@nic.cz> References: <20140414.085826.13684214630649317.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-1ku-Pn71DMbLvv6tRzWsuXY8D0 Cc: netmod@ietf.org Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:15:00 -0000 On 14 Apr 2014, at 08:58, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 13 Apr 2014, at 21:10, Tissa Senevirathne (tsenevir) >> wrote: >>=20 >>> Hi Lada >>>=20 >>> I want to validate say for example. >>>=20 >>> When "../../f:foo-1/f:ffoo-2 =3D 'bar' " >>>=20 >>> I could enter the path wrong, how can I check this using a tool >>>=20 >>> or I want to have multiple "or" combinations and want to check for = the >>> syntax of the XPath statement. >>=20 >> As far as I can tell, pyang does check syntax of XPath expressions. >=20 > Not really, it performs some very trivial syntax checks (runs a > scanner) but it doesn't check the grammar. >=20 >> The problem with paths is that they are not a priori wrong, they just >> may evaluate to an empty nodeset - and the evaluation can be = performed >> only in a context of an XML instance document, not at the time the >> YANG module is being validated. For example, an XPath expression may >> refer to a node that is defined in another module. >=20 > +1 >=20 > ... but the compiler should be able to warn about these situations. Yes, that would be useful, but either only on request or at least it = should be possible to turn this check off. It needs a complete data = model, and for multi-module models it could generate bogus warnings. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 14 00:20:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6F1A038E for ; Mon, 14 Apr 2014 00:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVcV4um0OWNZ for ; Mon, 14 Apr 2014 00:20:20 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 32E171A0324 for ; Mon, 14 Apr 2014 00:20:20 -0700 (PDT) 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 s3E7KGbY009313; Mon, 14 Apr 2014 09:20:16 +0200 Message-ID: <534B8C2D.1060804@mg-soft.com> Date: Mon, 14 Apr 2014 09:20:13 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <20140414.085826.13684214630649317.mbj@tail-f.com> <0697B38E-A297-4352-A38B-8A9B0E4182C9@nic.cz> In-Reply-To: <0697B38E-A297-4352-A38B-8A9B0E4182C9@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2fPvUW2KRp-O-zPPgimV4glXk3c Cc: netmod@ietf.org Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:20:25 -0000 Dne 14.4.2014 9:14, pie Ladislav Lhotka: > On 14 Apr 2014, at 08:58, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >>> On 13 Apr 2014, at 21:10, Tissa Senevirathne (tsenevir) >>> wrote: >>> >>>> Hi Lada >>>> >>>> I want to validate say for example. >>>> >>>> When "../../f:foo-1/f:ffoo-2 = 'bar' " >>>> >>>> I could enter the path wrong, how can I check this using a tool >>>> >>>> or I want to have multiple "or" combinations and want to check for the >>>> syntax of the XPath statement. >>> As far as I can tell, pyang does check syntax of XPath expressions. >> Not really, it performs some very trivial syntax checks (runs a >> scanner) but it doesn't check the grammar. >> >>> The problem with paths is that they are not a priori wrong, they just >>> may evaluate to an empty nodeset - and the evaluation can be performed >>> only in a context of an XML instance document, not at the time the >>> YANG module is being validated. For example, an XPath expression may >>> refer to a node that is defined in another module. >> +1 >> >> ... but the compiler should be able to warn about these situations. > Yes, that would be useful, but either only on request or at least it should be possible to turn this check off. It needs a complete data model, and for multi-module models it could generate bogus warnings. Why would this need a complete data model? An XPath expression can only reference names in the local an imported modules, right? All this requires is "cooked YANG". A compiler would be able to predict when an expression evaluates to an empty nodeset, but it cannot - not always. The reason is that expressions within reusable definitions (grouping, typedef) are poorly restricted in YANG. Any expression within a grouping should only be able to reference nodes defined within a grouping and typedefs should only be able to use absolute leafref paths. I wanted to raise a 1.1 issue about this, but it appears to be a 2.0 issue. Jernej > > Lada > >> >> /martin > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Apr 14 00:39:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367DD1A0395 for ; Mon, 14 Apr 2014 00:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9Sbx6sHToYL for ; Mon, 14 Apr 2014 00:39:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B10F31A027A for ; Mon, 14 Apr 2014 00:39:40 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C01E613F9D2; Mon, 14 Apr 2014 09:39:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1397461178; bh=m5cYRzD67nCD3+SQHGtM7njWJHM73ZjXlXQoJA52W7M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XAeppJDu+MNfcyQLtGrbjf3Ywll2LjlrHYtehjS5krR8s3/jukJ6nFk+F8UCFWPgc NA40HvVB9J7dE6sPMjrfqElTLsLeliwVWWUlyRFAd2snn4y4+dF1qVt5uaW/i1fxpo Fao94amzWYp1XpBYnVCRbY5tos6r5FFpxBhQGmJE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <534B8C2D.1060804@mg-soft.com> Date: Mon, 14 Apr 2014 09:39:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <46A1D336-3CCD-4D9B-BBB9-0E38AA89DB24@nic.cz> References: <20140414.085826.13684214630649317.mbj@tail-f.com> <0697B38E-A297-4352-A38B-8A9B0E4182C9@nic.cz> <534B8C2D.1060804@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uDLK3QsBwaTJJ_5GXfZTP_y3LPA Cc: netmod@ietf.org Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:39:45 -0000 On 14 Apr 2014, at 09:20, Jernej Tuljak = wrote: > Dne 14.4.2014 9:14, pi=9Ae Ladislav Lhotka: >> On 14 Apr 2014, at 08:58, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> On 13 Apr 2014, at 21:10, Tissa Senevirathne (tsenevir) >>>> wrote: >>>>=20 >>>>> Hi Lada >>>>>=20 >>>>> I want to validate say for example. >>>>>=20 >>>>> When "../../f:foo-1/f:ffoo-2 =3D 'bar' " >>>>>=20 >>>>> I could enter the path wrong, how can I check this using a tool >>>>>=20 >>>>> or I want to have multiple "or" combinations and want to check for = the >>>>> syntax of the XPath statement. >>>> As far as I can tell, pyang does check syntax of XPath expressions. >>> Not really, it performs some very trivial syntax checks (runs a >>> scanner) but it doesn't check the grammar. >>>=20 >>>> The problem with paths is that they are not a priori wrong, they = just >>>> may evaluate to an empty nodeset - and the evaluation can be = performed >>>> only in a context of an XML instance document, not at the time the >>>> YANG module is being validated. For example, an XPath expression = may >>>> refer to a node that is defined in another module. >>> +1 >>>=20 >>> ... but the compiler should be able to warn about these situations. >> Yes, that would be useful, but either only on request or at least it = should be possible to turn this check off. It needs a complete data = model, and for multi-module models it could generate bogus warnings. >=20 > Why would this need a complete data model? An XPath expression can = only reference names in the local an imported modules, right? All this = requires is "cooked YANG=94. You are right, unless the expression uses wildcards like *[local-name()=3D=91foo=92] But this should be very rare, so paths can be checked by default. >=20 > A compiler would be able to predict when an expression evaluates to an = empty nodeset, but it cannot - not always. The reason is that = expressions within reusable definitions (grouping, typedef) are poorly = restricted in YANG. Any expression within a grouping should only be able = to reference nodes defined within a grouping and typedefs should only be = able to use absolute leafref paths. I wanted to raise a 1.1 issue about = this, but it appears to be a 2.0 issue. Moreover, global typedefs (defined at the top level of a module) should = always use explicit prefixes. This could be added as a guideline in 6087bis. Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>>=20 >>> /martin >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=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 nobody Mon Apr 14 04:39:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950DB1A03CF for ; Mon, 14 Apr 2014 04:39:31 -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_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nfl58xg_u0E for ; Mon, 14 Apr 2014 04:39:27 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCA1A03C2 for ; Mon, 14 Apr 2014 04:39:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5D99A54027A; Mon, 14 Apr 2014 13:39:20 +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 WsyX09inPbaq; Mon, 14 Apr 2014 13:39:15 +0200 (CEST) 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 C527554000E; Mon, 14 Apr 2014 13:39:14 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , netmod@ietf.org In-Reply-To: <11909938.1397246854984.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> References: <11909938.1397246854984.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 14 Apr 2014 13:39:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kULdAoV5G1nWFHEptD2jcBJhzNM Subject: Re: [netmod] new issue: configuration versus state data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:39:31 -0000 Randy Presuhn writes: > Hi - > >>From: Ladislav Lhotka >>Sent: Apr 11, 2014 11:59 AM >>To: Randy Presuhn >>Cc: netmod@ietf.org >>Subject: Re: [netmod] new issue: configuration versus state data > ... >>I agree the concept of state datastore is not completely straightforward but >> >>- it is even worse to assume that it is a super-tree of the configuration tree, >> >>- a hierarchical data structure seems to be quite common - YANG, MIB, /proc, most CLIs. > ... > > It's an annoyance, but I don't see that aspect of the problem as > being substantially different from what is faced by the (sub)agent > developer for any other protocol: one must realistically start with > the assumption that the interoperable model will differ from managed > resource's native representation. Sometimes a little, sometimes a lot. > > If you're lucky, those differences will be mostly just how the bits > and pieces are identified and organized; those mappings are easily > dealt with in code-generating tools with the help of developer-provided > hints. Systematic mappings between data types are also tractable. > Where it gets messy (as in some of the cases you alluded to) is when > there are real differences in the semantics (including side-effects) > of multiple models/protocols accessing what should be the same > underlying information. I'd say the size of this problem is comparable to finding a common denominator for CLI data models of different vendors, i.e. something we've been dealing with in the past few years (I am not saying we've succeeded with that). > > I guess it depends on what one's expectations / vision for > netconf-based management are. If one is just looking for a > way to deliver more-or-less proprietary blobs of configuration > data, the expectations will be considerably less demanding > than those of someone looking for a full-blown management > protocol or an actual configuration management tool. In my view, the prospect of uniform remote configuration is quite appealing to operators but much less so to equipment vendors. What's actually happening is that new protocols are being designed whose main selling point is uniform (partial) configurability, and where a common data model could in fact suffice. Recent examples are OpenFlow and I2RS. > > Part of what it sounds like you're asking for is a better > integration between the protocol and the yang meta-model. I think I am rather asking for *decoupling* the protocol (NETCONF) from the YANG meta-model. Apart from some NETCONF-centric formulations in RFC 6020, it is the "config" statement and the option of embedding state data inside configuration that makes it difficult for other protocols to share state data with NETCONF in a safe and transparent way. Lada > The difficulty is that the latter doesn't seem to have been > worked out, and I'm sure some folks would say that this > is by design, and a feature rather than a bug. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 14 06:40:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE80A1A02C4; Mon, 14 Apr 2014 06:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSJqFNkt_abG; Mon, 14 Apr 2014 06:40:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA3B1A049A; Mon, 14 Apr 2014 06:40:24 -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: 5.2.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140414134024.24293.2148.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 06:40:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rVkDoDpaQazESbLHd_yzL2YPyJM Cc: netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'A YANG Data Model for IP Management' to Proposed Standard (draft-ietf-netmod-ip-cfg-14.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:40:31 -0000 The IESG has approved the following document: - 'A YANG Data Model for IP Management' (draft-ietf-netmod-ip-cfg-14.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ Technical Summary This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data, state data and counters for the collection of statistics. Working Group Summary The normal WG process was followed and the documents reflect WG consensus with nothing special worth mentioning except for the following. While the working group felt that the set of documents was complete in April 2013, there was a sense of unease about disparities between operational state and configuration. Additional reviews during the last call made it clear that it was desirable to deal with this by separating operational state from configuration management and that this should have been done from the beginning. The working group pulled the document back from IESG review and worked to add this to the model. Document Quality This set of documents received extensive review within the working group and ample time was spent to review and reconsider all design choices. The working group also reached out to the IP directorate and received additional review from Dave Thaler. Personnel Thomas Nadeau is the document shepherd Benoit Claise is the responsible Area Director. From nobody Mon Apr 14 07:41:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F81A047E for ; Mon, 14 Apr 2014 07:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKhNEOcS6Bgk for ; Mon, 14 Apr 2014 07:41:49 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 439191A03E7 for ; Mon, 14 Apr 2014 07:41:49 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so8839537qcx.38 for ; Mon, 14 Apr 2014 07:41:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QaeNDLyPNtEIcTJ5xjHh3cwq99ufDWMi1TwvPzYhRJc=; b=Od4VXeUfPuPnIWe/ZgzBllRLqNuEUhbQw97zJmeOOrN2/tX8vug2EWWotA8EP4KhZ5 8DaR7YZnP3WOI1c1CSZNEkVLhNg2+J24g2BOk+kdhG/JCw02f4jlPxTji5J1ETRaJwGo mh+BOnEJVfBJFcaroRou78M0uqsPRePpDore7/VOrDD0VUkS8itLrz7jbiH1auu6dnCz CgRl6SMhObtJ+krjg9i7IEty8Mg1m6hRYdxP1QaODEI50PIF/W6ZLStRa2WKOl4H/p8x RNerdUekcsChxwTbyCnQ2q+sukLEOcotpO9wiRQE1qFwsqnLjWjwLosH8i/YwEiOqU7b rwRg== X-Gm-Message-State: ALoCoQkgVQ+IE1z6hVT7HmLZERKU6vjEtP29FWu6Tq3X+ykDeFGbrtu/GDm7T3+0+sXWxFZGFyB2 MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr9170661qge.91.1397486506572; Mon, 14 Apr 2014 07:41:46 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 14 Apr 2014 07:41:46 -0700 (PDT) In-Reply-To: <46A1D336-3CCD-4D9B-BBB9-0E38AA89DB24@nic.cz> References: <20140414.085826.13684214630649317.mbj@tail-f.com> <0697B38E-A297-4352-A38B-8A9B0E4182C9@nic.cz> <534B8C2D.1060804@mg-soft.com> <46A1D336-3CCD-4D9B-BBB9-0E38AA89DB24@nic.cz> Date: Mon, 14 Apr 2014 07:41:46 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134f2becd912904f701ae59 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2H-RsXofpJvvu2sYFRSFH49BUWY Cc: "netmod@ietf.org" Subject: Re: [netmod] tool to check XPath in YANG ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:41:54 -0000 --001a1134f2becd912904f701ae59 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Mon, Apr 14, 2014 at 12:39 AM, Ladislav Lhotka wrote: > > On 14 Apr 2014, at 09:20, Jernej Tuljak wrote: > > > Dne 14.4.2014 9:14, pi=B9e Ladislav Lhotka: > >> On 14 Apr 2014, at 08:58, Martin Bjorklund wrote: > >> > >>> Ladislav Lhotka wrote: > >>>> On 13 Apr 2014, at 21:10, Tissa Senevirathne (tsenevir) > >>>> wrote: > >>>> > >>>>> Hi Lada > >>>>> > >>>>> I want to validate say for example. > >>>>> > >>>>> When "../../f:foo-1/f:ffoo-2 =3D 'bar' " > >>>>> > >>>>> I could enter the path wrong, how can I check this using a tool > >>>>> > >>>>> or I want to have multiple "or" combinations and want to check for > the > >>>>> syntax of the XPath statement. > >>>> As far as I can tell, pyang does check syntax of XPath expressions. > >>> Not really, it performs some very trivial syntax checks (runs a > >>> scanner) but it doesn't check the grammar. > >>> > >>>> The problem with paths is that they are not a priori wrong, they jus= t > >>>> may evaluate to an empty nodeset - and the evaluation can be perform= ed > >>>> only in a context of an XML instance document, not at the time the > >>>> YANG module is being validated. For example, an XPath expression may > >>>> refer to a node that is defined in another module. > >>> +1 > >>> > >>> ... but the compiler should be able to warn about these situations. > >> Yes, that would be useful, but either only on request or at least it > should be possible to turn this check off. It needs a complete data model= , > and for multi-module models it could generate bogus warnings. > > > > Why would this need a complete data model? An XPath expression can only > reference names in the local an imported modules, right? All this require= s > is "cooked YANG". > > You are right, unless the expression uses wildcards like > > *[local-name()=3D'foo'] > > But this should be very rare, so paths can be checked by default. > > > > > A compiler would be able to predict when an expression evaluates to an > empty nodeset, but it cannot - not always. The reason is that expressions > within reusable definitions (grouping, typedef) are poorly restricted in > YANG. Any expression within a grouping should only be able to reference > nodes defined within a grouping and typedefs should only be able to use > absolute leafref paths. I wanted to raise a 1.1 issue about this, but it > appears to be a 2.0 issue. > > Moreover, global typedefs (defined at the top level of a module) should > always use explicit prefixes. > > This could be added as a guideline in 6087bis. > > This is too restrictive. These are intermediate results. YANG allows complex constructs that need to be used correctly. Only the expanded usage in the 'cooked' YANG can be fully validated. Lada > > > > > Jernej > > > >> > >> Lada > >> > >>> > >>> /martin > Andy --001a1134f2becd912904f701ae59 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 14, 2014 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

    On 14 Apr 2014, at 09:20, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:

    > Dne 14.4.2014 9:14, pi=B9e Ladislav Lhotka:
    >> On 14 Apr 2014, at 08:58, Martin Bjorklund <mbj@tail-f.com> wrote:
    >>
    >>> Ladislav Lhotka <lhotka@ni= c.cz> wrote:
    >>>> On 13 Apr 2014, at 21:10, Tissa Senevirathne (tsenevir) >>>> <tsenevir@cisco.c= om> wrote:
    >>>>
    >>>>> Hi Lada
    >>>>>
    >>>>> I want to validate say for example.
    >>>>>
    >>>>> When "../../f:foo-1/f:ffoo-2 =3D 'bar' &q= uot;
    >>>>>
    >>>>> I could enter the path wrong, how can I check this usi= ng a tool
    >>>>>
    >>>>> or I want to have multiple "or" combinations= and want to check for the
    >>>>> syntax of the XPath statement.
    >>>> As far as I can tell, pyang does check syntax of XPath exp= ressions.
    >>> Not really, it performs some very trivial syntax checks (runs = a
    >>> scanner) but it doesn't check the grammar.
    >>>
    >>>> The problem with paths is that they are not a priori wrong= , they just
    >>>> may evaluate to an empty nodeset - and the evaluation can = be performed
    >>>> only in a context of an XML instance document, not at the = time the
    >>>> YANG module is being validated. For example, an XPath expr= ession may
    >>>> refer to a node that is defined in another module.
    >>> +1
    >>>
    >>> ... but the compiler should be able to warn about these situat= ions.
    >> Yes, that would be useful, but either only on request or at least = it should be possible to turn this check off. It needs a complete data mode= l, and for multi-module models it could generate bogus warnings.
    >
    > Why would this need a complete data model? An XPath expression can onl= y reference names in the local an imported modules, right? All this require= s is "cooked YANG”.

    You are right, unless the expression uses wildcards like

    *[local-name()=3D‘foo’]

    But this should be very rare, so paths can be checked by default.

    >
    > A compiler would be able to predict when an expression evaluates to an= empty nodeset, but it cannot - not always. The reason is that expressions = within reusable definitions (grouping, typedef) are poorly restricted in YA= NG. Any expression within a grouping should only be able to reference nodes= defined within a grouping and typedefs should only be able to use absolute= leafref paths. I wanted to raise a 1.1 issue about this, but it appears to= be a 2.0 issue.

    Moreover, global typedefs (defined at the top level of a module) should alw= ays use explicit prefixes.

    This could be added as a guideline in 6087bis.


    This is too restrictive.  These a= re intermediate results.
    YANG allows complex constructs that need= to be used correctly.
    Only the expanded usage in the 'cooked= ' YANG can be fully validated.


    Lada

    >
    > Jernej
    >
    >>
    >> Lada
    >>
    >>>
    >>> /martin


    Andy

    --001a1134f2becd912904f701ae59-- From nobody Tue Apr 15 09:39:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AB11A07B7 for ; Tue, 15 Apr 2014 09:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOo3HYFl9D6g for ; Tue, 15 Apr 2014 09:39:19 -0700 (PDT) Received: from snt0-omc3-s33.snt0.hotmail.com (snt0-omc3-s33.snt0.hotmail.com [65.55.90.172]) by ietfa.amsl.com (Postfix) with ESMTP id 045B01A048C for ; Tue, 15 Apr 2014 09:39:18 -0700 (PDT) Received: from SNT147-W46 ([65.55.90.135]) by snt0-omc3-s33.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Apr 2014 09:39:16 -0700 X-TMN: [fvwsAzki1Ft1qxeZnCvcuIowqsAjTa2P] X-Originating-Email: [yuekunli@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_cf35cd9b-7e13-47d8-aa10-bb16c27fb38d_" From: YuekunLi To: "netmod@ietf.org" Date: Tue, 15 Apr 2014 09:39:16 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Apr 2014 16:39:16.0155 (UTC) FILETIME=[3D8FF8B0:01CF58C9] Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tJYADrcdmSbih0esyDF-5cj7ThY Subject: [netmod] Discussion on draft-huang-netmod-acl-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:39:21 -0000 --_cf35cd9b-7e13-47d8-aa10-bb16c27fb38d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IA0KSGkgTGlzYS9BbGV4L0FuZHksDQoNCkkgd2VudCB0aHJvdWdoICdkcmFmdC1odWFuZy1uZXRt b2QtYWNsLTAzJyBhbmQgaGFkIGEgZmV3IHBvaW50cyB0aGF0IEkgd291bGQgbGlrZSB0byBkaXNj dXNzIHdpdGggeW91IGd1eXMuDQogDQoxLiBJIGhhdmUgc29tZSBjb25jZXJuIG9uIHRoZSBuYW1l IG9mIHRoZSBmZWF0dXJlIHdlJ3JlIG1vZGVsaW5nIGhlcmUuDQogICAnU3RhdGVsZXNzIFBhY2tl dCBGaWx0ZXInIGlzIGFjY3VyYXRlIHRvIGRlc2NyaWJlIHRoaXMgZmVhdHVyZS4NCiAgIEhvd2V2 ZXIsIG5vbmUgb2YgdGhlIG1ham9yIHZlbmRvcnMgaW4gdGhlIGluZHVzdHJ5IG5hbWVkIHRoZWly IGZlYXR1cmVzIGFzIHN1Y2guDQogICBBbGlnbmluZyB3aXRoIHNvbWUgbWFqb3IgdmVuZG9ycyB3 b3VsZCBiZSBhcHByb3ByaWF0ZSBzaW5jZSB3ZSdyZSBzZXR0aW5nIGEgc3RhbmRhcmQuDQogICBG cm9tIHRoaXMgcGVyc3BlY3RpdmUsIEkgd291bGQgc3VnZ2VzdCB1c2luZyAnQWNjZXNzIENvbnRy b2wgTGlzdCAoQUNMKScuDQogDQoyLiBUaGUgbGF0ZXN0IHJldmlzaW9uIG9mIHRoaXMgZG9jIGJy aWVmbHkgbWVudGlvbmVkIGhvdyBhIFNQRiAoQUNMKSBpcyBhcHBsaWVkIHRvIGEgdGFyZ2V0Lg0K ICAgSSBjYW4gc2VlIHRoYXQgc2VjdGlvbiAzLjMuNCBjb3ZlcnMgdGhlIHRvcGljIG9mIGF0dGFj aGluZyBhIFNQRiAoQUNMKSB0byBhbiBpbnRlcmZhY2UuDQogICBJbiB0aGlzIGNhc2UsIFNQRiAo QUNMKSBpcyB1c2VkIGZvciB0cmFmZmljIGZpbHRlcmluZy4NCiAgIFRoZXJlIGFyZSBxdWl0ZSBz b21lIHNjZW5hcmlvcywgaG93ZXZlciwgU1BGcyAoQUNMcykgYXJlIGRlcGxveWVkIGluIG90aGVy IGNsaWVudCBhcHBsaWNhdGlvbnMgc3VjaCBhcyBRb1MgcG9saWN5IGFuZCByb3V0aW5nIHByb3Rv Y29scyAoZS5nLiBCR1AgYW5kIE9TUEYpLg0KICAgSW4gbW9zdCBvZiB0aGVzZSBjYXNlcywgU1BG IChBQ0wpIGlzIHVzZWQgZm9yIGNsYXNzaWZpY2F0aW9uIG9yIGZpbHRlcmluZyBzb21lIHJvdXRp bmcgaW5mb3JtYXRpb24uDQogICBXb3VsZCB5b3UgY29uc2lkZXIgdG8gaW5pdGlhdGUgYSBuZXcg ZHJhZnQgZGVkaWNhdGVkIHRvIHRvcGljcyBvZiBhcHBseWluZyBTUEYgKEFDTCkgdG8gZWFjaCB0 eXBlIG9mIHRhcmdldHM/DQogDQozLiBUaGlzIGRvY3VtZW50IGhhcyBoYWQgYSBkZXRhaWxlZCBj b3ZlcmFnZSBvbiBvYmplY3QtZ3JvdXBzIChib3RoIHBvcnQgb2JqZWN0LWdyb3VwcyBhbmQgbmV0 d29yayBvYmplY3QtZ3JvdXBzKS4NCiAgIENvdWxkIHdlIGNvbnNpZGVyIHRvIHB1dCBvYmplY3Qt Z3JvdXBzIGluIGEgc2VwYXJhdGUgbW9kdWxlPw0KICAgVGhlIGJlbmVmaXQgb2YgdGhpcyBwcmFj dGljZSBpcyB0aGF0IGl0J3MgZWFzeSBmb3Igb2JqZWN0LWdyb3VwcyB0byBiZSByZS11c2VkIGJ5 IG90aGVyIG1vZHVsZXMgYmVzaWRlcyBTUEYgKEFDTCkuDQogDQo0LiBUaGUgcGFja2V0LWNhcHR1 cmUgZmVhdHVyZSBtYXkgbm90IGJlIGFwcHJvcHJpYXRlIGluIFNQRiAoQUNMKSBtb2R1bGUuDQog ICBUaGlzIGZlYXR1cmUgYWN0dWFsbHkgaW50cm9kdWNlcyBzb21lIG5ldyAnYWN0aW9ucycgdG8g ZXhlY3V0ZSBhZnRlciB3ZSBmb3VuZCBhIG1hdGNoIGJldHdlZW4gcGFja2V0IGFuZCBTUEUgKEFD RSkuDQogICBUaGVzZSBhY3Rpb25zIChmb3J3YXJkIGFuZCBjb3B5KSBhcmUgbm90IHB1cmVseSBm aWx0ZXJpbmcgYWN0aW9ucy4gDQogICBUaGVyZWZvcmUsIHRoZXkgbWF5IG5vdCBmaXQgaW4gdGhl IFNQRiAoQUNMKSBtb2R1bGUgdmVyeSB3ZWxsLg0KIA0KNS4gSW4gY3VycmVudCBTUEYgKEFDTCkg bW9kdWxlLCBlYWNoIFNQRSAoQUNFKSBpcyBhc3NpZ25lZCBhIHN0cmluZyBhcyBpdHMgbmFtZS4N CiAgIFRoaXMgbWF5IGJlIHRvbyBleHBlbnNpdmUgaW4gdGVybXMgb2YgbWVtb3J5IGNvbnN1bXB0 aW9uLg0KICAgSW5zdGVhZCwgYSBzZXF1ZW5jZSBudW1iZXIgZm9yIGVhY2ggZW50cnkgc2hvdWxk IGJlIHN1ZmZpY2llbnQgYW5kIGVhc3kgdG8gaW1wbGVtZW50Lg0KICAgQmVzaWRlcywgc2VxdWVu Y2UgbnVtYmVyIGRvZXMgZ2l2ZSB1c2VzIHRoZSBmbGV4aWJpbHR5IHRvIGluc2VydCBhbiBlbnRy eSB0byBjZXJ0YWluIHBvc2l0aW9uIG9mIGFuIGV4aXN0aW5nIFNQRiAoQUNMKS4NCiANCjYuIElz IGl0IGJldHRlciB0byBoYXZlIGEgaGlnaGVyIGxldmVsIGFic3RyYWN0aW9uIGFib3ZlIFNQRiAo QUNMKSBtb2R1bGU/DQogICBCeSB0aGlzLCBJIG1lYW4gY3JlYXRpbmcgYSBzZXBhcmF0ZSBtb2R1 bGUgdGhhdCBkZWZpbmVzIHNvbWUgY29tbW9uIHR5cGVkZWYvZ3JvdXBpbmdzLg0KICAgQW5kIG5v dCBjb250YWluZXIgaW4gdGhpcyBtb2R1bGUuDQogICBJcyB0aGlzIGdvaW5nIHRvIGJlIGFuIGlt cHJvdmVtZW50IGZvciB0aGUgbW9kdWxhcml0eT8NCg0KIA0KUGxlYXNlIGxldCBtZSBrbm93IGlm IHRoZXJlIGlzIGFueSBjb25mdXNpb24gb24gYWJvdmUgcG9pbnRzLg0KIA0KIA0KVGhhbmtzDQog DQotLS0tLS0tLS0tLS0tLS0NCll1ZWt1biBMaQ0KIAkJIAkgICAJCSAg --_cf35cd9b-7e13-47d8-aa10-bb16c27fb38d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5Os6iyO3RxbraDQp9DQotLT48L3N0eWxlPjwvaGVhZD4NCjxib2R5IGNsYXNzPSdo bW1lc3NhZ2UnPjxkaXYgZGlyPSdsdHInPjxmb250IHNpemU9IjMiIGZhY2U9IkFyaWFsIj48L2Zv bnQ+Jm5ic3A7PEJSPjxmb250IHNpemU9IjMiIGZhY2U9IkFyaWFsIj5IaSBMaXNhL0FsZXgvQW5k eSw8L2ZvbnQ+PEJSPjxmb250IGZhY2U9IkFyaWFsIj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iQXJpYWwiPjxicj5JIHdlbnQgdGhyb3VnaCZuYnNwOydkcmFmdC1odWFuZy1uZXRtb2QtYWNs LTAzJyBhbmQgaGFkIGEgZmV3IHBvaW50cyB0aGF0IEkgd291bGQgbGlrZSB0byBkaXNjdXNzIHdp dGggeW91IGd1eXMuPC9mb250PjxCUj48Zm9udCBzaXplPSIzIiBmYWNlPSJBcmlhbCI+PC9mb250 PiZuYnNwOzxCUj48Zm9udCBzaXplPSIzIiBmYWNlPSJBcmlhbCI+MS4gSSBoYXZlIHNvbWUgY29u Y2VybiBvbiB0aGUgbmFtZSBvZiB0aGUgZmVhdHVyZSB3ZSdyZSBtb2RlbGluZyBoZXJlLjxicj4m bmJzcDsmbmJzcDsgJ1N0YXRlbGVzcyBQYWNrZXQgRmlsdGVyJyBpcyBhY2N1cmF0ZSB0byBkZXNj cmliZSB0aGlzIGZlYXR1cmUuPGJyPiZuYnNwOyZuYnNwOyBIb3dldmVyLCBub25lIG9mIHRoZSBt YWpvciB2ZW5kb3JzIGluIHRoZSBpbmR1c3RyeSBuYW1lZCB0aGVpciBmZWF0dXJlcyBhcyBzdWNo Ljxicj4mbmJzcDsmbmJzcDsgQWxpZ25pbmcgd2l0aCBzb21lIG1ham9yIHZlbmRvcnMgd291bGQg YmUgYXBwcm9wcmlhdGUgc2luY2Ugd2UncmUgc2V0dGluZyBhIHN0YW5kYXJkLjxicj4mbmJzcDsm bmJzcDsgRnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBJIHdvdWxkIHN1Z2dlc3QgdXNpbmcgJ0FjY2Vz cyBDb250cm9sIExpc3QgKEFDTCknLjwvZm9udD48QlI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQXJp YWwiPjwvZm9udD4mbmJzcDs8QlI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjIuIFRoZSBs YXRlc3QgcmV2aXNpb24gb2YgdGhpcyBkb2MgYnJpZWZseSBtZW50aW9uZWQgaG93IGEgU1BGIChB Q0wpIGlzIGFwcGxpZWQgdG8gYSB0YXJnZXQuPGJyPiZuYnNwOyZuYnNwOyBJIGNhbiBzZWUgdGhh dCBzZWN0aW9uIDMuMy40IGNvdmVycyB0aGUgdG9waWMgb2YgYXR0YWNoaW5nIGEgU1BGIChBQ0wp IHRvIGFuIGludGVyZmFjZS48YnI+Jm5ic3A7Jm5ic3A7IEluIHRoaXMgY2FzZSwgU1BGIChBQ0wp IGlzIHVzZWQgZm9yIHRyYWZmaWMgZmlsdGVyaW5nLjxicj4mbmJzcDsmbmJzcDsgVGhlcmUgYXJl IHF1aXRlIHNvbWUgc2NlbmFyaW9zLCBob3dldmVyLCBTUEZzIChBQ0xzKSBhcmUgZGVwbG95ZWQg aW4gb3RoZXIgY2xpZW50IGFwcGxpY2F0aW9ucyBzdWNoIGFzIFFvUyBwb2xpY3kgYW5kIHJvdXRp bmcgcHJvdG9jb2xzIChlLmcuIEJHUCBhbmQgT1NQRikuPGJyPiZuYnNwOyZuYnNwOyBJbiBtb3N0 IG9mIHRoZXNlIGNhc2VzLCBTUEYgKEFDTCkgaXMgdXNlZCBmb3IgY2xhc3NpZmljYXRpb24gb3Ig ZmlsdGVyaW5nIHNvbWUgcm91dGluZyBpbmZvcm1hdGlvbi48YnI+Jm5ic3A7Jm5ic3A7IFdvdWxk IHlvdSBjb25zaWRlciB0byBpbml0aWF0ZSBhIG5ldyBkcmFmdCBkZWRpY2F0ZWQgdG8gdG9waWNz IG9mIGFwcGx5aW5nIFNQRiAoQUNMKSB0byBlYWNoIHR5cGUgb2YgdGFyZ2V0cz88L2ZvbnQ+PEJS Pjxmb250IHNpemU9IjMiIGZhY2U9IkFyaWFsIj48L2ZvbnQ+Jm5ic3A7PEJSPjxmb250IHNpemU9 IjMiIGZhY2U9IkFyaWFsIj4zLiBUaGlzIGRvY3VtZW50IGhhcyBoYWQgYSBkZXRhaWxlZCBjb3Zl cmFnZSBvbiBvYmplY3QtZ3JvdXBzIChib3RoIHBvcnQgb2JqZWN0LWdyb3VwcyBhbmQgbmV0d29y ayBvYmplY3QtZ3JvdXBzKS48YnI+Jm5ic3A7Jm5ic3A7IENvdWxkIHdlIGNvbnNpZGVyIHRvIHB1 dCBvYmplY3QtZ3JvdXBzIGluIGEgc2VwYXJhdGUgbW9kdWxlPzxicj4mbmJzcDsmbmJzcDsgVGhl IGJlbmVmaXQgb2YgdGhpcyBwcmFjdGljZSBpcyB0aGF0IGl0J3MgZWFzeSBmb3Igb2JqZWN0LWdy b3VwcyB0byBiZSByZS11c2VkIGJ5IG90aGVyIG1vZHVsZXMgYmVzaWRlcyBTUEYgKEFDTCkuPC9m b250PjxCUj48Zm9udCBzaXplPSIzIiBmYWNlPSJBcmlhbCI+PC9mb250PiZuYnNwOzxCUj48Zm9u dCBzaXplPSIzIiBmYWNlPSJBcmlhbCI+NC4gVGhlIHBhY2tldC1jYXB0dXJlIGZlYXR1cmUgbWF5 IG5vdCBiZSBhcHByb3ByaWF0ZSBpbiBTUEYgKEFDTCkgbW9kdWxlLjxicj4mbmJzcDsmbmJzcDsg VGhpcyBmZWF0dXJlIGFjdHVhbGx5IGludHJvZHVjZXMgc29tZSBuZXcgJ2FjdGlvbnMnIHRvIGV4 ZWN1dGUgYWZ0ZXIgd2UgZm91bmQgYSBtYXRjaCBiZXR3ZWVuIHBhY2tldCBhbmQgU1BFIChBQ0Up Ljxicj4mbmJzcDsmbmJzcDsgVGhlc2UgYWN0aW9ucyAoZm9yd2FyZCBhbmQgY29weSkgYXJlIG5v dCBwdXJlbHkgZmlsdGVyaW5nIGFjdGlvbnMuIDxicj4mbmJzcDsmbmJzcDsgVGhlcmVmb3JlLCB0 aGV5IG1heSBub3QgZml0IGluIHRoZSBTUEYgKEFDTCkgbW9kdWxlIHZlcnkgd2VsbC48L2ZvbnQ+ PEJSPjxmb250IHNpemU9IjMiIGZhY2U9IkFyaWFsIj48L2ZvbnQ+Jm5ic3A7PEJSPjxmb250IHNp emU9IjMiIGZhY2U9IkFyaWFsIj41LiBJbiBjdXJyZW50IFNQRiAoQUNMKSBtb2R1bGUsIGVhY2gg U1BFIChBQ0UpIGlzIGFzc2lnbmVkIGEgc3RyaW5nIGFzIGl0cyBuYW1lLjxicj4mbmJzcDsmbmJz cDsgVGhpcyBtYXkgYmUgdG9vIGV4cGVuc2l2ZSBpbiB0ZXJtcyBvZiBtZW1vcnkgY29uc3VtcHRp b24uPGJyPiZuYnNwOyZuYnNwOyBJbnN0ZWFkLCBhIHNlcXVlbmNlIG51bWJlciBmb3IgZWFjaCBl bnRyeSBzaG91bGQgYmUgc3VmZmljaWVudCBhbmQgZWFzeSB0byBpbXBsZW1lbnQuPGJyPiZuYnNw OyZuYnNwOyBCZXNpZGVzLCBzZXF1ZW5jZSBudW1iZXIgZG9lcyBnaXZlIHVzZXMgdGhlIGZsZXhp YmlsdHkgdG8gaW5zZXJ0IGFuIGVudHJ5IHRvIGNlcnRhaW4gcG9zaXRpb24gb2YgYW4gZXhpc3Rp bmcgU1BGIChBQ0wpLjwvZm9udD48QlI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjwvZm9u dD4mbmJzcDs8QlI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjYuIElzIGl0IGJldHRlciB0 byBoYXZlIGEgaGlnaGVyIGxldmVsIGFic3RyYWN0aW9uIGFib3ZlIFNQRiAoQUNMKSBtb2R1bGU/ PGJyPiZuYnNwOyZuYnNwOyBCeSB0aGlzLCBJIG1lYW4gY3JlYXRpbmcgYSBzZXBhcmF0ZSBtb2R1 bGUgdGhhdCBkZWZpbmVzIHNvbWUgY29tbW9uIHR5cGVkZWYvZ3JvdXBpbmdzLjxicj4mbmJzcDsm bmJzcDsgQW5kIG5vdCBjb250YWluZXIgaW4gdGhpcyBtb2R1bGUuPGJyPiZuYnNwOyZuYnNwOyBJ cyB0aGlzIGdvaW5nIHRvIGJlIGFuIGltcHJvdmVtZW50IGZvciB0aGUgbW9kdWxhcml0eT88L2Zv bnQ+PEJSPjxmb250IHNpemU9IjMiIGZhY2U9IkFyaWFsIj48YnI+Jm5ic3A7PEJSPlBsZWFzZSBs ZXQgbWUga25vdyBpZiB0aGVyZSBpcyBhbnkgY29uZnVzaW9uIG9uIGFib3ZlIHBvaW50cy48QlI+ Jm5ic3A7PEJSPiZuYnNwOzxCUj5UaGFua3M8QlI+Jm5ic3A7PEJSPi0tLS0tLS0tLS0tLS0tLTxi cj5ZdWVrdW4gTGk8L2ZvbnQ+PEJSPiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_cf35cd9b-7e13-47d8-aa10-bb16c27fb38d_-- From nobody Tue Apr 15 11:00:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEDD1A0489; Tue, 15 Apr 2014 11:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh1uhB8-TSFv; Tue, 15 Apr 2014 11:00:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3B71A0368; Tue, 15 Apr 2014 11:00:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140415180016.31500.51645.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 11:00:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SFgm2k6KBfTp22mIv0K_y2vmKVw Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-14.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:00:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for System Management Authors : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-14.txt Pages : 40 Date : 2014-04-15 Abstract: This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a NETCONF server. This includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 15 17:42:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D41B1A008D for ; Tue, 15 Apr 2014 17:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBVpj10trpmG for ; Tue, 15 Apr 2014 17:42:15 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by ietfa.amsl.com (Postfix) with ESMTP id 472581A008A for ; Tue, 15 Apr 2014 17:42:15 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id j5so10528578qga.18 for ; Tue, 15 Apr 2014 17:42:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=y6gJxlTNN2PGLU48vgWHdZHdQjVOwg3zYMrway4TSe8=; b=SPJ9FQoQ74mZmWPiFo2auJH2fh1uW6KbkBjImpY9wK8pU3UAdeRw3vzXAgUMH5lKwr pNMPNrQU60nRUndgH/N5quQoAi1ozU66iWSnNr022Ry22gff22o+zWFTC7PTaPeKU6R4 SPZG4cUtNkpHw+oIuhyRmQmpEGCK6ppYsMOKRiUVu7zNqnz+a8feAy11MUqOTVKPgytS tvW7b5gsrAk8o6OsFFSqkfnklatjCJlKk4gPDQFn0sWb9b3kkpG5/dIS+GddPz17ue43 CNUW5WWKfXi/QPOsJATl4E+aEkzCipB5EhJvpdE9z/mK2bknNPRFKGoXZyyjH9oPXTAP EP9w== X-Gm-Message-State: ALoCoQn55qjPSuVURNOI6Ed+iJ3mokIOgyIW0qjbQKc0q4iPVyXhF0wTFLlKd8/zYZxHprUEIRiP MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr1418322qaa.7.1397608932004; Tue, 15 Apr 2014 17:42:12 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 15 Apr 2014 17:42:11 -0700 (PDT) Date: Tue, 15 Apr 2014 17:42:11 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bea3986ed66bc04f71e2fa4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9z_eBmfk30kqpFBwuu3B5jv9r2Q Subject: [netmod] new YANG 1.1 issues: empty in union X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 00:42:17 -0000 --047d7bea3986ed66bc04f71e2fa4 Content-Type: text/plain; charset=ISO-8859-1 Hi, There are 3 issues in this email: Issue 1) empty data type representation not complete in RFC 6020 9.11.4. Usage Example The following leaf leaf enable-qos { type empty; } will be encoded as * * if it exists. The text in 9.11.4 above is mis-leading. The form ** is also acceptable. Issue 2) ABNF for not correct in RFC 6020 for union-specification union-specification = 1*(type-stmt stmtsep) type-stmt = type-keyword sep identifier-ref-arg-str optsep (";" / "{" stmtsep type-body-stmts "}") type-body-stmts = numerical-restrictions / decimal64-specification / string-restrictions / enum-specification / leafref-specification / identityref-specification / instance-identifier-specification / bits-specification / union-specification >From sec. 9.12: A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref". The ABNF allows both 'empty' and 'leafref' types to be specified,even though they are not allowed for 'union-specification' Issue 3) Allow "empty" in union-specification types The following is illegal in YANG: type union { type int32; type empty; } But the following equivalent encoding is allowed: type union { type int32; type string { length 0; } } Why is "empty" prohibited when a zero-length string is OK, and it is encoded exactly the same as an empty type in XML messages. Andy --047d7bea3986ed66bc04f71e2fa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,


    There are 3 issues i= n this email:

    Issue 1) empty data type representat= ion not complete in RFC 6020
    9.11.4.  Usage Example
    
       The following leaf
    
         leaf enable-qos {
             type empty;
         }
    
       will be encoded as
    
         <enable-qos/>
    
       if it exists.
    The text in 9.11.4 a=
    bove is mis-leading.
    The form <enable-qos></enable-qos> is also acceptable.

    Issue 2) ABNF for not correct in RFC 6020 for union-specification=
    

       union-specifica=
    tion =3D 1*(type-stmt stmtsep)
       type-stmt           =3D type-keyword sep identifier-ref-arg-str optsep
                             (";" /
                              "{" stmtsep
                                  type-body-stmts
                              "}")
    
       type-body-stmts     =3D numerical-restrictions /
                             decimal64-specification /
                             string-restrictions /
                             enum-specification /
                             leafref-specification /
                             identityref-specification /
                             instance-identifier-specification /
                             bits-specification /
                             union-specification
    From sec. 9.12:
       A member type can be of any built-in =
    or derived type, except it MUST
       NOT be one of the built-in types "empty" or "leafref"=
    ;.
    The ABNF allows both 'empty' and 'leafr=
    ef' types to be specified,
    even though they are not allowed f=
    or 'union-specification'

    Issue 3) Allow "empty" in union-specification typ=
    es
    The=
     following is illegal in YANG:
       type union {
          type int32;
          type empty;
       }
    But the =
    following equivalent encoding is allowed:
      type union {
          type int32;
          type string { length 0; }
       }

    Why is "emp=
    ty" prohibited when a zero-length string
    is OK, and it is encoded exactly the same as an
    empty type in XML messages.

    Andy
    <=
    br>
    

    --047d7bea3986ed66bc04f71e2fa4-- From nobody Wed Apr 16 05:24:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48681A014E for ; Wed, 16 Apr 2014 05:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvmHDKoOhj9L for ; Wed, 16 Apr 2014 05:24:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 877BF1A0145 for ; Wed, 16 Apr 2014 05:24:20 -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 5933137C35A; Wed, 16 Apr 2014 14:24:16 +0200 (CEST) Date: Wed, 16 Apr 2014 14:24:15 +0200 (CEST) Message-Id: <20140416.142415.639785467728991670.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fP-cp2kB2xUekzpUFb27JoLdlrU Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issues: empty in union X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 12:24:25 -0000 Andy Bierman wrote: > Hi, > > > There are 3 issues in this email: > > Issue 1) empty data type representation not complete in RFC 6020 > > 9.11.4. Usage Example > > The following leaf > > leaf enable-qos { > type empty; > } > > will be encoded as > > * * > > if it exists. > > The text in 9.11.4 above is mis-leading. > The form ** is also acceptable. I will change the text so that it is clear that this is just one example of a valid encoding. > Issue 2) ABNF for not correct in RFC 6020 for union-specification > > > union-specification = 1*(type-stmt stmtsep) > > type-stmt = type-keyword sep identifier-ref-arg-str optsep > (";" / > "{" stmtsep > type-body-stmts > "}") > > type-body-stmts = numerical-restrictions / > decimal64-specification / > string-restrictions / > enum-specification / > leafref-specification / > identityref-specification / > instance-identifier-specification / > bits-specification / > union-specification > > >From sec. 9.12: > > A member type can be of any built-in or derived type, except it MUST > NOT be one of the built-in types "empty" or "leafref". > > The ABNF allows both 'empty' and 'leafref' types to be specified,even > though they are not allowed for 'union-specification' Ok, but if we do Y30 and Y35, the grammar will be correct :) > Issue 3) Allow "empty" in union-specification types > > The following is illegal in YANG: > > type union { > type int32; > type empty; > } > > But the following equivalent encoding is allowed: > > type union { > type int32; > type string { length 0; } > } > > > Why is "empty" prohibited when a zero-length string > is OK, and it is encoded exactly the same as an > empty type in XML messages. I agree. Added as Y35. /martin From nobody Wed Apr 16 06:38:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860901A01A6 for ; Wed, 16 Apr 2014 06:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5MAGFGnkSbo for ; Wed, 16 Apr 2014 06:38:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9011A0193 for ; Wed, 16 Apr 2014 06:38:52 -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 0E9E837C35B; Wed, 16 Apr 2014 15:38:48 +0200 (CEST) Date: Wed, 16 Apr 2014 15:38:47 +0200 (CEST) Message-Id: <20140416.153847.1855299557610867624.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nlJXvAr1FRA-4kR2xATNt5Rc0qg Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: notification resource identification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:38:56 -0000 Hi, This is now Y36. (BTW, the html at the wiki is now readable) /martin Andy Bierman wrote: > Hi, > > Problem: > > NETCONF/YANG does not have a general mechanism > to associate a data node with a notification event. > A common feature (required by I2RS) is the ability > to associate a notification with a resource instance. > > Solution: > > YANG should define some common mechanism to indicate > that a notification-stmt is associated with a data resource object. > This can only be done now with description-stmt text. > > Possible implementation: > > * Allow the path-stmt to be present as a sub-statement > of the notification-stmt. > > notification interface-enabled { > path "/if:interfaces/if:interface"; > leaf name { > type leafref { > path "/if:interfaces/if:interface/if:name"; > } > } > } > > The "name" leaf does not define the resource in a way that > a generic tool can figure out the resource object. A tool would > need to be coded separately to support each notification-stmt. > > The path-stmt allows the resource object to be easily identified. > It would not be present unless there is a data resource object > associated with the event type. > > > Andy From nobody Wed Apr 16 06:39:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551DB1A0193 for ; Wed, 16 Apr 2014 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DDHEXnBBBDu for ; Wed, 16 Apr 2014 06:39:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEFE1A0187 for ; Wed, 16 Apr 2014 06:39:04 -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 79F45240C32B; Wed, 16 Apr 2014 15:39:00 +0200 (CEST) Date: Wed, 16 Apr 2014 15:39:00 +0200 (CEST) Message-Id: <20140416.153900.2050674012136018983.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UpQZltZmPmQIHqqqJaeu6U59bKw Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: notification reuse X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:39:08 -0000 Hi, Added as Y37. /martin Andy Bierman wrote: > Hi, > > Problem: > > YANG notficaition-stmt allows other modules to augment an event > with data but there is no common way to derive new event types > from existing event types. > > Solution: > > A mechanism is needed in YANG to allow new notifications to be > defined that extend existing notifications. Conceptually, the contents > of a base notification are added the new notification > > Possible implementation: > > * Add a base-notification statement as a sub-statement of > notification-stmt > > notification interface-event { > path "/if:interfaces/if:interface"; > leaf name { > type leafref { > path "/if:interfaces/if:interface/if:name"; > } > } > } > > notification interface-enabled { > base-notification "if:interface-event"; > // new objects can be added here > } > > notification interface-disabled { > base-notification "if:interface-event"; > // new objects can be added here > } > > The YANG compiler treats the base-notification-stmt as a conceptual > "uses" statement and the base notification is treated like a grouping, > except the entire contents are used, not just data-def-stmts. > > > Andy From nobody Sat Apr 19 08:54:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB01A0012 for ; Sat, 19 Apr 2014 08:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UBX7ApDZSF7 for ; Sat, 19 Apr 2014 08:54:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 27C771A001E for ; Sat, 19 Apr 2014 08:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7626; q=dns/txt; s=iport; t=1397922839; x=1399132439; h=from:to:subject:date:message-id:mime-version; bh=WjKyVxOv9MuVFUPO0y7rDZR0w+tsmcunMM6NBLw3DRI=; b=Zae5l2e2zykSQ6epipKX7i/uyd4IvCMxabEbYkGCmsUdCJVXNIwaPQqj NJCBRAY5KhLjDK2CnWEFbsRXaUY7YvraRRAw7BmzvuDEo0uwSkQfudms5 UKQQ5eSI5ZJSGP6Ij6AcJyOUnizoDLIsQFplLQEgXCKZusf3RnHC5ss+v M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFALOaUlOtJA2H/2dsb2JhbABZgkJET1fEBYEcFnSCJwEELV4BKlYmAQQbAYg4DZpfslYXjjGDXIEUBKs9gzGCKw X-IronPort-AV: E=Sophos;i="4.97,889,1389744000"; d="scan'208,217";a="318950083" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 19 Apr 2014 15:53:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3JFrwYs014871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 19 Apr 2014 15:53:58 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.226]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Sat, 19 Apr 2014 10:53:58 -0500 From: "Tissa Senevirathne (tsenevir)" To: "netmod@ietf.org" Thread-Topic: how to interpret complexity score of YANG dump Thread-Index: Ac9b5446orBXCOHnTpmRbmmpu4kWrQ== Date: Sat, 19 Apr 2014 15:53:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.121.44] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFC035Bxmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ytHusUs1CsS8vnYk2opcjxOv6f8 Subject: [netmod] how to interpret complexity score of YANG dump X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 15:54:07 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFC035Bxmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I am using ynagdump (http://www.netconfcentral.org/run_yangdump) utility to= pass YANG models. Under statistics it gives a complexity score. Below I ha= ve cut and pasted complexity of ietf-routing.yang. Questions: 1. How does the complexity score derived 2. Assuming higher the number more complex, how can one reduce it ? i= n other word what contributes more to the complexity score? 3. Is there any guidelines on recommended complexity level of a YANG = module Ietf-routing,yang statistics Statistics: Complexity score: 2576 Total Nodes: 134 Extensions: 0 Features: 2 .. Thanks Tissa --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFC035Bxmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi


    I am using ynagdump (http://www.netconfcentral.org/run_yangdump) utility to pass YANG model= s. Under statistics it gives a complexity score. Below I have cut and paste= d complexity of ietf-routing.yang.

     

    Questions:

     

    1.     &= nbsp; How does the complexity score derived

    2.     &= nbsp; Assuming higher the number more complex, how can on= e reduce it ? in other word what contributes more to the complexity score?<= o:p>

    3.     &= nbsp; Is there any guidelines on recommended complexity l= evel of a YANG module

     

    Ietf-routing,yang statistics

     

    Statistics:

    Complexity score: 2576=

    Total Nodes: 134

    Extensions: 0

    Features: 2

    ..

     

    Thanks

    Tissa

     

    --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFC035Bxmbrcdx08ciscoc_-- From nobody Sat Apr 19 12:13:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781A01A004C for ; Sat, 19 Apr 2014 12:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIbgLNFTtgpc for ; Sat, 19 Apr 2014 12:13:49 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4E1A0024 for ; Sat, 19 Apr 2014 12:13:48 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j5so2617016qaq.14 for ; Sat, 19 Apr 2014 12:13:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D/BPa46t/0Ia4us66G0guziw3ISD0koCECA2fN82/CY=; b=da4aekjx0RY5f2BgZH/yhqgBgPmoRHt5yBQJoGoXnyVCn67P9fEdugERffg54UwGDc z9vnoaObDIb31NWGC+WDJPpDrUSX5mptkuOI+Q8y75EZvDXb20Lq6GboNSoTyGocRnAb utSn/20fzh1fod8RA/5jJzXPhZnRTgNbWX9bM7BWSM0fYRKUsPen62Tl4wKoNrg53HyE /qRm6svTPV/w5H9VkTHhGVtTgHPDFLqLTbAD4nrEuLX8dxvqMmJ10duZxcogoNZ26CfA qKflYXySml5sHFZocBBwDD0r+Tf48AmOLQ8jt5eijfY37edLBEQOfUwRqTjSfpI7ej/S 7b6w== X-Gm-Message-State: ALoCoQlyVcOj5nG96hqSrlq6iG7trM5W3Qa/6jKPfKrZT3VQAQJWULUjfghqVQRxY8Z9np4F7qRT MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr25941110qge.91.1397934824505; Sat, 19 Apr 2014 12:13:44 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sat, 19 Apr 2014 12:13:44 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 Apr 2014 12:13:44 -0700 Message-ID: From: Andy Bierman To: "Tissa Senevirathne (tsenevir)" Content-Type: multipart/alternative; boundary=001a1134f2bea256f504f76a107f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4_PmR7qOS7S-cOTvtqimj9Yllzo Cc: "netmod@ietf.org" Subject: Re: [netmod] how to interpret complexity score of YANG dump X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:13:53 -0000 --001a1134f2bea256f504f76a107f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 19, 2014 at 8:53 AM, Tissa Senevirathne (tsenevir) < tsenevir@cisco.com> wrote: > Hi > > > I am using ynagdump (http://www.netconfcentral.org/run_yangdump) utility > to pass YANG models. Under statistics it gives a complexity score. Below I > have cut and pasted complexity of ietf-routing.yang. > > > > Questions: > > > > 1. How does the complexity score derived > > 2. Assuming higher the number more complex, how can one reduce it ? > in other word what contributes more to the complexity score? > > 3. Is there any guidelines on recommended complexity level of a > YANG module > > > This is some code I wrote back in 2010. I don't remember all the details, but the code is still the same in the OpenYuma code (look in yangstats.c and yangstats.h). The idea was to come up with a metric to estimate implementation complexity and readability complexity. I never tried to tune the weight factors so they correlated to any measured data (so they are probably wrong). Andy > Ietf-routing,yang statistics > > > > Statistics: > > Complexity score: 2576 > > Total Nodes: 134 > > Extensions: 0 > > Features: 2 > > .. > > > > Thanks > > Tissa > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a1134f2bea256f504f76a107f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Sat, Apr 19, 2014 at 8:53 AM, Tissa Senevirathne (tsenevir) <t= senevir@cisco.com> wrote:

    Hi


    I am using ynagdump (http://www.netconfcentral.org/run_yangdump) utility = to pass YANG models. Under statistics it gives a complexity score. Below I = have cut and pasted complexity of ietf-routing.yang.

    =A0

    Questions:

    =A0

    1.= =A0=A0=A0=A0=A0=A0 How does the complexity score derived

    2.= =A0=A0=A0=A0=A0=A0 Assuming higher the number more complex, how can one r= educe it ? in other word what contributes more to the complexity score?<= /u>

    3.= =A0=A0=A0=A0=A0=A0 Is there any guidelines on recommended complexity leve= l of a YANG module

    =A0




    This is some code I wrote back in 2010= .
    I don't remember all the details, but the code is still the= same in
    the OpenYuma code (look in yangstats.c and yangstats.h).
    The idea was to come up with a metric to estimate implementatio= n complexity
    and readability complexity. =A0I never tried to tune= the weight factors so they
    correlated to any measured data (so they are probably wrong).


    Andy

    =A0

    Ietf-routing,yang statistics

    =A0

    Statistics:

    Complexity score: 2576

    Total Nodes: 134

    Extensions: 0

    Features: 2

    ..

    =A0

    Thanks

    Tissa

    =A0


    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod


    --001a1134f2bea256f504f76a107f-- From nobody Mon Apr 21 05:25:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBFB1A0208 for ; Mon, 21 Apr 2014 05:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl9Sok1Cxoiz for ; Mon, 21 Apr 2014 05:25:40 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 07C7D1A0207 for ; Mon, 21 Apr 2014 05:25:39 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id w7so3991692qcr.11 for ; Mon, 21 Apr 2014 05:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Qd/EJtqqQ/YcbMal8DBqxZbE5BkleRBBKiBRSDTfkZ0=; b=FUev8pKzm0TuoiqB33wjDziVgCaGrvswNiQpsADgLHcxMfZe0f9VtcoAXE3D/1Wqab a9gGVrkwWMH7LrvtFjcQKdOQsRcK+p3DSu1YwnNKgaNf094a/CcxvGlkCn688b4W37hd KwmyrOT72QXbAUQQNAACPhMtEzANCN/Y2qysME8jLIin8kMrEUzQzwMigtxWTT4xvGih aaYmpx963KCXiO3YutReFLg0TXGJGQUvIyrSfSK9SQLGv3qXw1VkVd43g9MObhathFWm NJbCUH6CuI8Dgs1Lw5MaTh9UWViOU8YpV22zMbgOJbKJtQ5G03ESvQVE/gg5zLVF1jFo nLVg== MIME-Version: 1.0 X-Received: by 10.224.44.17 with SMTP id y17mr41171838qae.36.1398083134840; Mon, 21 Apr 2014 05:25:34 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Mon, 21 Apr 2014 05:25:34 -0700 (PDT) Date: Mon, 21 Apr 2014 20:25:34 +0800 Message-ID: From: chong feng To: netmod@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc88e49e623204f78c98a2 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eqA4x2maH91MK5CVFpSaHOIv3t8 Subject: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 12:25:41 -0000 --047d7bdc88e49e623204f78c98a2 Content-Type: text/plain; charset=UTF-8 Hi all, I suggest add 'mandatory' to container to solve the problem listed below: container a { leaf b; leaf c; } user can set b or set c or set b and c,but at least one is assigned. So, I suggest add 'mandatory' to container to express this situation. If a container is mandatory, at least one sub path of this container should be selected when the instance associated with this container is created. The container with presence must not be set "mandatory true". --047d7bdc88e49e623204f78c98a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi all,
    =C2=A0 =C2=A0 I suggest add 'mandatory'= ; to container to solve the problem listed below:
    =C2=A0 =C2=A0 c= ontainer a {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf b;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf c;
    =C2=A0 =C2=A0 }
    =

    =C2=A0 =C2=A0 user can set b or set c or set b and c,but at = least one is assigned.

    =C2=A0 =C2=A0So, I suggest = add 'mandatory' to container to express this situation. If a contai= ner is mandatory, at least one sub path of this container should be selecte= d when the instance associated with this container is created. The containe= r with presence must not be set "mandatory true".
    --047d7bdc88e49e623204f78c98a2-- From nobody Mon Apr 21 06:13:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C908C1A0219 for ; Mon, 21 Apr 2014 06:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIsPu55JyxQ4 for ; Mon, 21 Apr 2014 06:13:29 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3D1A021D for ; Mon, 21 Apr 2014 06:13:24 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id f51so1985034qge.24 for ; Mon, 21 Apr 2014 06:13:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DX96Q4TOtk8qYGtOAP0mKehv4X+GajKVkv/K6PB1PyM=; b=K4OI/6ACS4ZzxER6wIJMMqDuw1M3E4viMKeL35aCGUFsV99oRXZuCF5q3k9wdeGeSW G/jBbD/lyUlroOPZbdc+C4o6FR36juPcZQUXw3xqkZzN3jmmdqBGlHXSHqJH8LOIjAgs 8Q1dwF6/rlpXS1HGloItB4rdl5Zae1oVQlfHZUqFXlitLYkqVk/9BUjMwAu1mxVNpqCr Tfzmy0yra8PE/l9T50wcv3/3IkveFLD+cEHyabKRtuz8ajVFZG8NmODH0FqMT2cJurHo MscQe/MoNqZdNbgqVdVjPvsx0NtyMr9GzHIpvK0VmJLP+BcxvRmuFij40qGMHnSmXxgF VGEg== X-Gm-Message-State: ALoCoQlcRURzU/cgsnyzvjwYNCkOr5q+K3CmGP/92suiE/BWOIMKkoq33y7ZpnKC0lbj7MaSls0I MIME-Version: 1.0 X-Received: by 10.140.98.116 with SMTP id n107mr3496556qge.94.1398085999611; Mon, 21 Apr 2014 06:13:19 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 06:13:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Apr 2014 06:13:19 -0700 Message-ID: From: Andy Bierman To: chong feng Content-Type: multipart/alternative; boundary=001a113a92385f657704f78d4391 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kPozV9vkBFNr5WSxS44upOX7xzc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 13:13:31 -0000 --001a113a92385f657704f78d4391 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 21, 2014 at 5:25 AM, chong feng wrote: > Hi all, > I suggest add 'mandatory' to container to solve the problem listed > below: > container a { > leaf b; > leaf c; > } > > user can set b or set c or set b and c,but at least one is assigned. > > You can use must-stmt: container a { must "b or c"; leaf b { ...} leaf c {...} } Top-level mandatory nodes are not allowed in IETF YANG modules, so in order to make 'a' mandatory, it has to be a child node of something: container top { must "a"; container a { ... } } > So, I suggest add 'mandatory' to container to express this situation. > If a container is mandatory, at least one sub path of this container should > be selected when the instance associated with this container is created. > The container with presence must not be set "mandatory true". > > An NP-container has no semantics. It is just a way of collecting nodes under a common parent node. So mandatory is not relevant for NP-container. NP-container is a corner-case node because it is transparent to default and mandatory, meaning child nodes can make the container a default or mandatory already. container a { must "b or c"; // always true leaf b { type int32; default 42; } leaf c { type string; } leaf d { mandatory true; type int32; } } The node /a/b always exists wrt/ XPath evaluation. Container 'a' is mandatory because leaf 'd' is mandatory. Andy --001a113a92385f657704f78d4391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 21, 2014 at 5:25 AM, chong feng <<= a href=3D"mailto:fengchongllly@gmail.com" target=3D"_blank">fengchongllly@g= mail.com> wrote:
    Hi all,
    =A0 =A0 I sugge= st add 'mandatory' to container to solve the problem listed below:<= /div>
    =A0 =A0 container a {
    =A0 =A0 =A0 =A0 =A0 leaf b;
    =A0 = =A0 =A0 =A0 =A0 leaf c;
    =A0 =A0 }

    =A0 =A0 user can set b or set c or set b and c,but at least = one is assigned.



    You can use must-stmt:

    =A0 =A0cont= ainer a {
    =A0 =A0 =A0 must "b or c";
    =A0 =A0 =A0 leaf b { ..= .}
    =A0 =A0 =A0 leaf c {...}
    =A0 =A0}

    Top-level mandatory nodes are not allowed in IETF YANG modules,
    so in order to make 'a' mandatory, it has to be a child node = of something:

    =A0 container top {
    =A0 =A0 =A0must "a&q= uot;;
    =A0 =A0 =A0container a { ... }
    =A0 }
    =A0
    =A0 =A0So, I suggest add 'mandatory= 9; to container to express this situation. If a container is mandatory, at = least one sub path of this container should be selected when the instance a= ssociated with this container is created. The container with presence must = not be set "mandatory true".


    An NP-container has no semantics. =A0I= t is just a way of collecting nodes
    under a common parent node. = =A0So mandatory is not relevant for NP-container.
    NP-container is= a corner-case node because it is transparent to default and mandatory,
    meaning child nodes can make the container a default or mandatory alre= ady.

    =A0container a {
    =A0 =A0must "= b or c"; =A0 // always true
    =A0 =A0leaf b { type int32; defa= ult 42; }
    =A0 =A0leaf c { type string; }
    =A0 =A0leaf d { mandatory tru= e; type int32; }
    =A0}


    The= node /a/b always exists wrt/ XPath evaluation.
    Container 'a&= #39; is mandatory because leaf 'd' is mandatory.


    Andy


    =
    --001a113a92385f657704f78d4391-- From nobody Mon Apr 21 09:58:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990A91A018F for ; Mon, 21 Apr 2014 09:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVoURdq86KiI for ; Mon, 21 Apr 2014 09:58:04 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 00C6B1A0198 for ; Mon, 21 Apr 2014 09:58:03 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id 63so823765qgz.23 for ; Mon, 21 Apr 2014 09:57:58 -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 :cc:content-type; bh=mLHdbLDpS00eaiSZS639np2yWKKJ5OB6+qt3zKGy15E=; b=Rogl7MiDlheCtca1AbEHiU6bmuGgqVi7G9eAWYwFc+/RckM52ldnjXABs1P6EOe5QK xTtbiVUFeqRIEU9/liPnmZ0J70kHWnqesRKa2/muZl6unlgWKFy63lwFpsC//8Dvm4GO F8rr6znmi1ddO03DFpd/OBhX9iNPMF7BgzGErNfffZ3HQc9BOia/JoioZN6XSkUiTHoh G6C2r+pwKGE8s/Rb/piU8IGwI/VqlA9YzcpzteL5y13L8ZlJOhkGGlqSIS/5I/9BfFor 2+BJza8dFPIA+0jiQzXWFDXdjV6456nonhIbf3+8v4lzpqTtzYC/CZLx0XrkfNeZhyr5 4qJg== MIME-Version: 1.0 X-Received: by 10.140.105.118 with SMTP id b109mr46005878qgf.28.1398099478676; Mon, 21 Apr 2014 09:57:58 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Mon, 21 Apr 2014 09:57:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Apr 2014 00:57:58 +0800 Message-ID: From: chong feng To: Andy Bierman Content-Type: multipart/alternative; boundary=001a1137d4a4c9877f04f790661f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ryAKMhNC52mSiii19a23maHaxY4 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 16:58:05 -0000 --001a1137d4a4c9877f04f790661f Content-Type: text/plain; charset=UTF-8 Hi andy, I don't think 'must' is a good solution. For example: The hierarchy of data def is below: module test { container a { container b { container c { container d { leaf e; leaf f; } } } } } if use 'must' ,it should be : module test { container a { must b; container b { must c; container c { must d; container d { must "e or f"; leaf e; leaf f; } } } } } but container a can be not selected, because 'must' expression only be evaluated when container a is exists. if use 'mandatory', it should be: module test { container a { container b { container c { container d { mandatory true; leaf e; leaf f; } } } } } container a must be selected when the data is created. If a NP-container is just a path node, then the container 'd' will be not a common NP-container, It's also represent a logical relation(one or more sub path must be selected). Should we add a new datadef stmt? for example, multi-choice? for example: module test { container a { container b { container c { multi-choice d { mandatory true; leaf e; leaf f; } } } } } > On Mon, Apr 21, 2014 at 5:25 AM, chong feng wrote: > >> Hi all, >> I suggest add 'mandatory' to container to solve the problem listed >> below: >> container a { >> leaf b; >> leaf c; >> } >> >> user can set b or set c or set b and c,but at least one is assigned. >> >> > > You can use must-stmt: > > container a { > must "b or c"; > leaf b { ...} > leaf c {...} > } > > Top-level mandatory nodes are not allowed in IETF YANG modules, > so in order to make 'a' mandatory, it has to be a child node of something: > > container top { > must "a"; > container a { ... } > } > > > >> So, I suggest add 'mandatory' to container to express this situation. >> If a container is mandatory, at least one sub path of this container should >> be selected when the instance associated with this container is created. >> The container with presence must not be set "mandatory true". >> >> > An NP-container has no semantics. It is just a way of collecting nodes > under a common parent node. So mandatory is not relevant for NP-container. > NP-container is a corner-case node because it is transparent to default > and mandatory, > meaning child nodes can make the container a default or mandatory already. > > container a { > must "b or c"; // always true > leaf b { type int32; default 42; } > leaf c { type string; } > leaf d { mandatory true; type int32; } > } > > > The node /a/b always exists wrt/ XPath evaluation. > Container 'a' is mandatory because leaf 'd' is mandatory. > > > Andy > > > --001a1137d4a4c9877f04f790661f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi andy,
    =C2=A0 =C2=A0I don't think 'must'= is a good solution.
    =C2=A0 =C2=A0For example:
    =C2=A0 = =C2=A0The hierarchy of data def is below:
    =C2=A0 =C2=A0module tes= t {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 container a {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container b {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 co= ntainer c {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container d {
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf e;
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0leaf f;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 }<= /div>

    if use 'must' ,it should be :
    =C2=A0 =C2=A0module test {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 container a {
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 must b;
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 container b {
    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 must c;
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container c {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 must d;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 container d {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0must "e or f";
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0leaf e;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0leaf f;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 }

    but conta= iner a can be not selected, because 'must' expression only be=C2=A0= evaluated when container a is exists.

    if use '= ;mandatory', it should be:
    =C2=A0 = =C2=A0module test {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 container a {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container b {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = container c {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container d {
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf e;
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0leaf f;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 }<= /div>
    =C2=A0
    container a must be selected when the data is created.

    If a NP-con= tainer is just a path node, then the container 'd' will be =C2=A0no= t a common NP-container, It's also represent a logical
    relation(one or more sub path must be selected).

    Should we add a new datadef stmt= ? for example, multi-choice?

    for example:
    =C2=A0 =C2=A0module test = {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 container a {
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container b {
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container c {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 multi-choice d {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf e;
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf f;
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 }
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 }
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
    = On Mon, Apr 21, 2014 at 5:25 AM, chong feng <fengchongllly@gmail.c= om> wrote:
    Hi all,
    =C2=A0 =C2=A0 I suggest add 'mandator= y' to container to solve the problem listed below:
    =C2=A0 =C2=A0 container a {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 le= af b;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf c;
    =C2=A0= =C2=A0 }

    =C2=A0 =C2=A0 user can set b or set c or set b and c,but at = least one is assigned.



    You can use must-stmt:

    =C2=A0 =C2=A0container a {
    =C2=A0 =C2=A0 =C2=A0 must "b or c";
    =C2=A0 =C2=A0 = =C2=A0 leaf b { ...}
    =C2=A0 =C2=A0 =C2=A0 leaf c {...}
    = =C2=A0 =C2=A0}

    Top-level mandatory nodes are not a= llowed in IETF YANG modules,
    so in order to make 'a' mand= atory, it has to be a child node of something:

    =C2=A0 container top {
    =C2=A0 =C2=A0 =C2=A0mu= st "a";
    =C2=A0 =C2=A0 =C2=A0container a { ... }
    =C2=A0 }

    =C2=A0
    =C2=A0 =C2=A0So, I suggest add 'mandatory' to = container to express this situation. If a container is mandatory, at least = one sub path of this container should be selected when the instance associa= ted with this container is created. The container with presence must not be= set "mandatory true".


    An NP-container has no semantics= . =C2=A0It is just a way of collecting nodes
    under a common paren= t node. =C2=A0So mandatory is not relevant for NP-container.
    NP-c= ontainer is a corner-case node because it is transparent to default and man= datory,
    meaning child nodes can make the container a default or mandatory alre= ady.

    =C2=A0container a {
    =C2=A0 =C2=A0mu= st "b or c"; =C2=A0 // always true
    =C2=A0 =C2=A0leaf b = { type int32; default 42; }
    =C2=A0 =C2=A0leaf c { type string; }
    =C2=A0 =C2=A0leaf d { m= andatory true; type int32; }
    =C2=A0}

    The node /a/b always exists wrt/ XPath evaluation.
    Co= ntainer 'a' is mandatory because leaf 'd' is mandatory.


    Andy


    =

    --001a1137d4a4c9877f04f790661f-- From nobody Mon Apr 21 10:58:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588CB1A0252 for ; Mon, 21 Apr 2014 10:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXGN_Zi9LMLU for ; Mon, 21 Apr 2014 10:57:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4E62E1A0242 for ; Mon, 21 Apr 2014 10:57:47 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 41E3B13F9C5; Mon, 21 Apr 2014 19:57:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398103061; bh=ezliGrAXT4PFffSXd5Y25yggR97ZcxmGyoNmxqBXBA4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ExjgiNB2kHgYsxW/s++Xl+AcYQE/nvY0kvT86qtFzXfp52Wsilmktq2z6hkseg2b0 igDw3F5y+HqEaVxdPTLGBjGKonGgv/E5JVljNbqEVAvXj4TC+jETJP3CLxXb3CczgK KMb9tjFGQ3s4sWqKTan2f1cnQAt1Y568BlM6RcPw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 21 Apr 2014 19:57:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zzDKjliv8G5Ug48xxyNZzGvJPZk Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 17:57:51 -0000 On 21 Apr 2014, at 15:13, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Apr 21, 2014 at 5:25 AM, chong feng = wrote: > Hi all, > I suggest add 'mandatory' to container to solve the problem listed = below: > container a { > leaf b; > leaf c; > } >=20 > user can set b or set c or set b and c,but at least one is = assigned. >=20 >=20 >=20 > You can use must-stmt: >=20 > container a { > must "b or c"; > leaf b { ...} > leaf c {...} > } This doesn=92t work. If container =93a" doesn=92t exist in the data = tree, the must constraint doesn=92t apply (second paragraph in sec. = 7.5.3). Lada >=20 > Top-level mandatory nodes are not allowed in IETF YANG modules, > so in order to make 'a' mandatory, it has to be a child node of = something: >=20 > container top { > must "a"; > container a { ... } > } >=20 > =20 > So, I suggest add 'mandatory' to container to express this = situation. If a container is mandatory, at least one sub path of this = container should be selected when the instance associated with this = container is created. The container with presence must not be set = "mandatory true". >=20 >=20 > An NP-container has no semantics. It is just a way of collecting = nodes > under a common parent node. So mandatory is not relevant for = NP-container. > NP-container is a corner-case node because it is transparent to = default and mandatory, > meaning child nodes can make the container a default or mandatory = already. >=20 > container a { > must "b or c"; // always true > leaf b { type int32; default 42; } > leaf c { type string; } > leaf d { mandatory true; type int32; } > } >=20 >=20 > The node /a/b always exists wrt/ XPath evaluation. > Container 'a' is mandatory because leaf 'd' is mandatory. >=20 >=20 > Andy >=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 nobody Mon Apr 21 12:28:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495501A026C for ; Mon, 21 Apr 2014 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6BjdJ5kXTfl for ; Mon, 21 Apr 2014 12:28:41 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3603F1A0250 for ; Mon, 21 Apr 2014 12:28:41 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id k15so4244172qaq.1 for ; Mon, 21 Apr 2014 12:28:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pQKAU6MT5REqvO8LFV0yuFl/PPOvDZJ+PTHBQY0Lxvs=; b=bz7DZvjLPFLtL2vhaIDkNceFBHU/k8GghBeQFk5SYVEZ5qjAoRZIE8KzrZWlGOdyhP wVMe6Q0ueiF96Qv1af2wSuzn4f4F8SDZXD62ILug8B8iCAfGDQfDFSRYTuc/dFObQHDi 51H7mq6qT9GS7YjDk5CYfFOhJAPvptGEko7OO2AlZBXiHFlhyooe/M61mNfkdO6vzQyB wwrPehlbpFmKbP95DK5lubYgUqVD3+g/MSwgZWCLOQDIc+VB0jkskkPOnJ8e8FAl43no gRHlRXz86esgfUNFAA0CuskQ9GTIWHVkQc4sjbQQHzlz7GGP8sHrRNbqxPUVhPmnIPQ6 O8uQ== X-Gm-Message-State: ALoCoQlbqKb9osg/LcYCz476Kcro1fsfs18dSaNn1ekdPe628iKGB64a2BD1JoUGEbjVu5XHTArN MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr6629743qad.88.1398108515836; Mon, 21 Apr 2014 12:28:35 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 12:28:35 -0700 (PDT) In-Reply-To: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> Date: Mon, 21 Apr 2014 12:28:35 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e0158a9e471c94c04f7928177 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/waARs4slMsRwbaqRocOGURpXJ08 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:28:46 -0000 --089e0158a9e471c94c04f7928177 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 21, 2014 at 10:57 AM, Ladislav Lhotka wrote: > > On 21 Apr 2014, at 15:13, Andy Bierman wrote: > > > > > > > > > On Mon, Apr 21, 2014 at 5:25 AM, chong feng > wrote: > > Hi all, > > I suggest add 'mandatory' to container to solve the problem listed > below: > > container a { > > leaf b; > > leaf c; > > } > > > > user can set b or set c or set b and c,but at least one is assigned. > > > > > > > > You can use must-stmt: > > > > container a { > > must "b or c"; > > leaf b { ...} > > leaf c {...} > > } > > This doesn't work. If container "a" doesn't exist in the data tree, the > must constraint doesn't apply (second paragraph in sec. 7.5.3). > > I understand that. Top-level mandatory nodes are not allowed in IETF YANG modules because they are implementation-dependent. As soon as the module is loaded, the configuration is invalid because the mandatory node is missing. I do not agree NP-containers need the mandatory-stmt. > Lada > Andy > > > > Top-level mandatory nodes are not allowed in IETF YANG modules, > > so in order to make 'a' mandatory, it has to be a child node of > something: > > > > container top { > > must "a"; > > container a { ... } > > } > > > > > > So, I suggest add 'mandatory' to container to express this situation. > If a container is mandatory, at least one sub path of this container should > be selected when the instance associated with this container is created. > The container with presence must not be set "mandatory true". > > > > > > An NP-container has no semantics. It is just a way of collecting nodes > > under a common parent node. So mandatory is not relevant for > NP-container. > > NP-container is a corner-case node because it is transparent to default > and mandatory, > > meaning child nodes can make the container a default or mandatory > already. > > > > container a { > > must "b or c"; // always true > > leaf b { type int32; default 42; } > > leaf c { type string; } > > leaf d { mandatory true; type int32; } > > } > > > > > > The node /a/b always exists wrt/ XPath evaluation. > > Container 'a' is mandatory because leaf 'd' is mandatory. > > > > > > Andy > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --089e0158a9e471c94c04f7928177 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 21, 2014 at 10:57 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

    On 21 Apr 2014, at 15:13, Andy Bierman <andy@yumaworks.com> wrote:

    >
    >
    >
    > On Mon, Apr 21, 2014 at 5:25 AM, chong feng <fengchongllly@gmail.com> wrote:
    > Hi all,
    >     I suggest add 'mandatory' to container to solve = the problem listed below:
    >     container a {
    >           leaf b;
    >           leaf c;
    >     }
    >
    >     user can set b or set c or set b and c,but at least one = is assigned.
    >
    >
    >
    > You can use must-stmt:
    >
    >    container a {
    >       must "b or c";
    >       leaf b { ...}
    >       leaf c {...}
    >    }

    This doesn’t work. If container “a" doesn’t exist in= the data tree, the must constraint doesn’t apply (second paragraph i= n sec. 7.5.3).



    I understand that.
    Top-level mandatory nodes are not allowed in IETF YANG modules
    <= div>because they are implementation-dependent.  As soon as the module = is
    loaded, the configuration is invalid because the mandatory node
    <= div>is missing.

    I do not agree NP-containers need = the mandatory-stmt.

     
    Lada
     

    Andy

    >
    > Top-level mandatory nodes are not allowed in IETF YANG modules,
    > so in order to make 'a' mandatory, it has to be a child node o= f something:
    >
    >   container top {
    >      must "a";
    >      container a { ... }
    >   }
    >
    >
    >    So, I suggest add 'mandatory' to container to exp= ress this situation. If a container is mandatory, at least one sub path of = this container should be selected when the instance associated with this co= ntainer is created. The container with presence must not be set "manda= tory true".
    >
    >
    > An NP-container has no semantics.  It is just a way of collecting= nodes
    > under a common parent node.  So mandatory is not relevant for NP-= container.
    > NP-container is a corner-case node because it is transparent to defaul= t and mandatory,
    > meaning child nodes can make the container a default or mandatory alre= ady.
    >
    >  container a {
    >    must "b or c";   // always true
    >    leaf b { type int32; default 42; }
    >    leaf c { type string; }
    >    leaf d { mandatory true; type int32; }
    >  }
    >
    >
    > The node /a/b always exists wrt/ XPath evaluation.
    > Container 'a' is mandatory because leaf 'd' is mandato= ry.
    >
    >
    > Andy
    >
    >
    > _______________________________________________
    > netmod mailing list
    > netmod@ietf.org
    > https://www.ietf.org/mailman/listinfo/netmod

    --
    Ladislav Lhotka, CZ.NIC Labs
    PGP Key ID: E74E8C0C





    --089e0158a9e471c94c04f7928177-- From nobody Mon Apr 21 12:52:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2599E1A0270 for ; Mon, 21 Apr 2014 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqqlfElj_fT5 for ; Mon, 21 Apr 2014 12:52:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id AF3261A0257 for ; Mon, 21 Apr 2014 12:52:32 -0700 (PDT) Received: from pluto.hedeland.org (h118n4-hy-d5.ias.bredband.telia.com [81.224.106.118]) by mail.tail-f.com (Postfix) with ESMTPSA id ADF9B3B41C5; Mon, 21 Apr 2014 21:52:26 +0200 (CEST) Message-ID: <535576FA.8040401@tail-f.com> Date: Mon, 21 Apr 2014 21:52:26 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ladislav Lhotka References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> In-Reply-To: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T4_Dyf8MGJi8BVAZOdl1WUfM9L8 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:52:37 -0000 On 2014-04-21 19:57, Ladislav Lhotka wrote: > > On 21 Apr 2014, at 15:13, Andy Bierman wrote: > >> >> >> >> On Mon, Apr 21, 2014 at 5:25 AM, chong feng wrote: >> Hi all, >> I suggest add 'mandatory' to container to solve the problem listed below: >> container a { >> leaf b; >> leaf c; >> } >> >> user can set b or set c or set b and c,but at least one is assigned. >> >> >> >> You can use must-stmt: >> >> container a { >> must "b or c"; >> leaf b { ...} >> leaf c {...} >> } > > This doesnt work. If container a" doesnt exist in the data tree, the must constraint doesnt apply (second paragraph in sec. 7.5.3). You seem to be assuming that the suggested "mandatory" on a container should be radically different from the existing "mandatory" on leafs and choices - why? If container a doesn't exist, "mandatory" on e.g. leaf b has no effect - nor should the suggested "mandatory" on container a, meaning "b and/or c must be set", have any effect. Consider container p { presence "foo"; container a { mandatory true; // new suggestion leaf b {...} leaf c {...} } } If p doesn't exist, it would be completely unreasonable for the "mandatory" on a to force p into existence - and without that, obviously neither b nor c could be set. At least it would be completely at odds with the semantics of the existing "mandatory" statement. Bottom line, "must" works just as well/bad as the new suggestion. --Per From nobody Mon Apr 21 13:12:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AB71A02B9 for ; Mon, 21 Apr 2014 13:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjqrYxaUh1pP for ; Mon, 21 Apr 2014 13:12:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 362191A02A7 for ; Mon, 21 Apr 2014 13:11:44 -0700 (PDT) Received: from pluto.hedeland.org (h118n4-hy-d5.ias.bredband.telia.com [81.224.106.118]) by mail.tail-f.com (Postfix) with ESMTPSA id BB870476C3C; Mon, 21 Apr 2014 22:11:38 +0200 (CEST) Message-ID: <53557B7A.5020306@tail-f.com> Date: Mon, 21 Apr 2014 22:11:38 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ladislav Lhotka References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> In-Reply-To: <535576FA.8040401@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AudjxpCZ9d_WFzMpt_3DCfUxpGQ Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:12:31 -0000 On 2014-04-21 21:52, Per Hedeland wrote: > On 2014-04-21 19:57, Ladislav Lhotka wrote: >> >> On 21 Apr 2014, at 15:13, Andy Bierman wrote: >> >>> >>> >>> >>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng wrote: >>> Hi all, >>> I suggest add 'mandatory' to container to solve the problem listed below: >>> container a { >>> leaf b; >>> leaf c; >>> } >>> >>> user can set b or set c or set b and c,but at least one is assigned. >>> >>> >>> >>> You can use must-stmt: >>> >>> container a { >>> must "b or c"; >>> leaf b { ...} >>> leaf c {...} >>> } >> >> This doesnt work. If container a" doesnt exist in the data tree, the must constraint doesnt apply (second paragraph in sec. 7.5.3). > > You seem to be assuming that the suggested "mandatory" on a container > should be radically different from the existing "mandatory" on leafs and > choices - why? If container a doesn't exist, "mandatory" on e.g. leaf b > has no effect - nor should the suggested "mandatory" on container a, > meaning "b and/or c must be set", have any effect. Consider > > container p { > presence "foo"; > container a { > mandatory true; // new suggestion > leaf b {...} > leaf c {...} > } > } > > If p doesn't exist, it would be completely unreasonable for the > "mandatory" on a to force p into existence - and without that, obviously > neither b nor c could be set. At least it would be completely at odds > with the semantics of the existing "mandatory" statement. > > Bottom line, "must" works just as well/bad as the new suggestion. Hm, or are you saying that, with container p { presence "foo"; container a { must "b or c"; leaf b {...} leaf c {...} } } - the "must" wouldn't apply even if p existed? In that case there probably needs to be some clarification of what it means for a np-container to "exist" for the purpose of "must" evaluation. Our implementation certainly considers a to "exist" if p exists (regardless of whether either of b and c exists) - and any other interpretation seems bizarre to me, but maybe it isn't 110% clear from 6020... --Per From nobody Mon Apr 21 13:36:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77F61A029B for ; Mon, 21 Apr 2014 13:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqO5gdoDv0fL for ; Mon, 21 Apr 2014 13:36:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54B1A0281 for ; Mon, 21 Apr 2014 13:36:39 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BE39113F7A0; Mon, 21 Apr 2014 22:36:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398112592; bh=fNOr6yeNyIOYsODy4HrdYbvJjdzq6zCnUubI0CBPmwM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sEaiMGp2vxlv5k8//H/lL1rR7XH7nXDtv2pDGxdundCd366L/qVbWTDPVoPZXa9w1 pdKA/1o34smTuRLAxwjrlzR94RxXVgnVqQi/U6HzfbbCy77GHI5ic5xhmx7LO5i/wE q8H6il3roUHGh+Y/0JrEZr1hhap5VBB6yXQ6EQUI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <53557B7A.5020306@tail-f.com> Date: Mon, 21 Apr 2014 22:36:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> To: Per Hedeland X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IR5p7YzarwPmEAGqQ_Wag7hnggg Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:36:46 -0000 On 21 Apr 2014, at 22:11, Per Hedeland wrote: > On 2014-04-21 21:52, Per Hedeland wrote: >> On 2014-04-21 19:57, Ladislav Lhotka wrote: >>>=20 >>> On 21 Apr 2014, at 15:13, Andy Bierman wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng = wrote: >>>> Hi all, >>>> I suggest add 'mandatory' to container to solve the problem = listed below: >>>> container a { >>>> leaf b; >>>> leaf c; >>>> } >>>>=20 >>>> user can set b or set c or set b and c,but at least one is = assigned. >>>>=20 >>>>=20 >>>>=20 >>>> You can use must-stmt: >>>>=20 >>>> container a { >>>> must "b or c"; >>>> leaf b { ...} >>>> leaf c {...} >>>> } >>>=20 >>> This doesn=19t work. If container =1Ca" doesn=19t exist in the data = tree, the must constraint doesn=19t apply (second paragraph in sec. = 7.5.3). >>=20 >> You seem to be assuming that the suggested "mandatory" on a container >> should be radically different from the existing "mandatory" on leafs = and >> choices - why? If container a doesn't exist, "mandatory" on e.g. leaf = b >> has no effect - nor should the suggested "mandatory" on container a, >> meaning "b and/or c must be set", have any effect. Consider >>=20 >> container p { >> presence "foo"; >> container a { >> mandatory true; // new suggestion >> leaf b {...} >> leaf c {...} >> } >> } >>=20 >> If p doesn't exist, it would be completely unreasonable for the >> "mandatory" on a to force p into existence - and without that, = obviously >> neither b nor c could be set. At least it would be completely at odds >> with the semantics of the existing "mandatory" statement. >>=20 >> Bottom line, "must" works just as well/bad as the new suggestion. >=20 > Hm, or are you saying that, with >=20 > container p { > presence "foo"; > container a { > must "b or c"; > leaf b {...} > leaf c {...} > } > } >=20 > - the "must" wouldn't apply even if p existed? In that case there Sure, if =93a=94 doesn=92t exist. > probably needs to be some clarification of what it means for a > np-container to "exist" for the purpose of "must" evaluation. Our > implementation certainly considers a to "exist" if p exists = (regardless > of whether either of b and c exists) - and any other interpretation > seems bizarre to me, but maybe it isn't 110% clear from 6020=85 Bizarre? Sec. 7.5.8: If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container. Lada >=20 > --Per -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 21 14:08:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B19E1A0296 for ; Mon, 21 Apr 2014 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myr6PokqKE3m for ; Mon, 21 Apr 2014 14:08:13 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 92F121A02C4 for ; Mon, 21 Apr 2014 14:08:13 -0700 (PDT) Received: from pluto.hedeland.org (h118n4-hy-d5.ias.bredband.telia.com [81.224.106.118]) by mail.tail-f.com (Postfix) with ESMTPSA id 43BD53B41C5; Mon, 21 Apr 2014 23:08:07 +0200 (CEST) Message-ID: <535588B7.3080401@tail-f.com> Date: Mon, 21 Apr 2014 23:08:07 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ladislav Lhotka References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> In-Reply-To: <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yf1Q89i1MFsl06V91jqIV4jtYxE Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:08:19 -0000 On 2014-04-21 22:36, Ladislav Lhotka wrote: > > On 21 Apr 2014, at 22:11, Per Hedeland wrote: > >> On 2014-04-21 21:52, Per Hedeland wrote: >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: >>>> >>>> On 21 Apr 2014, at 15:13, Andy Bierman wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng wrote: >>>>> Hi all, >>>>> I suggest add 'mandatory' to container to solve the problem listed below: >>>>> container a { >>>>> leaf b; >>>>> leaf c; >>>>> } >>>>> >>>>> user can set b or set c or set b and c,but at least one is assigned. >>>>> >>>>> >>>>> >>>>> You can use must-stmt: >>>>> >>>>> container a { >>>>> must "b or c"; >>>>> leaf b { ...} >>>>> leaf c {...} >>>>> } >>>> >>>> This doesnt work. If container a" doesnt exist in the data tree, the must constraint doesnt apply (second paragraph in sec. 7.5.3). >>> >>> You seem to be assuming that the suggested "mandatory" on a container >>> should be radically different from the existing "mandatory" on leafs and >>> choices - why? If container a doesn't exist, "mandatory" on e.g. leaf b >>> has no effect - nor should the suggested "mandatory" on container a, >>> meaning "b and/or c must be set", have any effect. Consider >>> >>> container p { >>> presence "foo"; >>> container a { >>> mandatory true; // new suggestion >>> leaf b {...} >>> leaf c {...} >>> } >>> } >>> >>> If p doesn't exist, it would be completely unreasonable for the >>> "mandatory" on a to force p into existence - and without that, obviously >>> neither b nor c could be set. At least it would be completely at odds >>> with the semantics of the existing "mandatory" statement. >>> >>> Bottom line, "must" works just as well/bad as the new suggestion. >> >> Hm, or are you saying that, with >> >> container p { >> presence "foo"; >> container a { >> must "b or c"; >> leaf b {...} >> leaf c {...} >> } >> } >> >> - the "must" wouldn't apply even if p existed? In that case there > > Sure, if a doesnt exist. > >> probably needs to be some clarification of what it means for a >> np-container to "exist" for the purpose of "must" evaluation. Our >> implementation certainly considers a to "exist" if p exists (regardless >> of whether either of b and c exists) - and any other interpretation >> seems bizarre to me, but maybe it isn't 110% clear from 6020& > > Bizarre? Sec. 7.5.8: > > If a container does not have a "presence" statement and the last > child node is deleted, the NETCONF server MAY delete the container. The point is - and this *is* expressed in 6020 (7.5.1) - that the "existence" of a np-container has no semantics. What you are saying (and 6020 doesn't really contradict you) is that container p { presence "foo"; container a { leaf b { type ...; mandatory true; } } } and container p { presence "foo"; container a { must "b"; leaf b { type ...; } } } mean radically different things, and actually that the semantics of the latter is basically undefined, since it would depend on whether container a "happened to" exist, even though it can neither be created nor deleted explicitly, and its existence isn't supposed to have any semantics. I'm "pretty" sure this is not the intention of the authors. I seems what is needed is a clarification (in 7.5.3) of when the "must" statements of a np-container apply, similar to what is done for "mandatory" in 7.6.5. --Per From nobody Mon Apr 21 16:11:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B7F1A0301 for ; Mon, 21 Apr 2014 16:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfeL01sRfruU for ; Mon, 21 Apr 2014 16:11:17 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7B71A02D1 for ; Mon, 21 Apr 2014 16:11:17 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so4684821qcy.14 for ; Mon, 21 Apr 2014 16:11:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3lp6/vRqdFYeKlmLtuFXzMC/PgSjJb7pSnLSlZiL6co=; b=m4IRURwDo2iwJ15qcH3Rmq1UmrwiMneizppsW39AaCfzlfkIyKl32337b02Tljhfs9 mzcRdc0bizfIHv1s/1bKdfgmKorMHaWonTyBbLz0SxLlrYf9CIiL0EdK6PrXYDkvYLqc r/xLw1nHciqSHYy0Zye3YUQuU+9ZFqndd3b4ryggG76GGpSjis+zZQ9mV3w1jvJGCzB7 qtVLfPOE8mF50A420+1OfxrY8ftAdS+cWjIm6jJCEnDf8vr8QQRaLbyLDeHrluohdBEy pe3xpfyGLKrRTDsHp4zcFaZIrLHeTCtM2vvCcHHAbJdkOBWtgo9l1rR4TNiqSJLkpCbe v2Hg== X-Gm-Message-State: ALoCoQk2CG9cV7YQXfRz5j/FsdyCBb2Knb+BhfiCYne2l3VUlZC3byJTQACX6h0KIcDfY8MixQN2 MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr29333149qge.34.1398121872212; Mon, 21 Apr 2014 16:11:12 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 16:11:12 -0700 (PDT) In-Reply-To: <535588B7.3080401@tail-f.com> References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> Date: Mon, 21 Apr 2014 16:11:12 -0700 Message-ID: From: Andy Bierman To: Per Hedeland Content-Type: multipart/alternative; boundary=001a113abfd88bd9f604f7959d52 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yE1LKPoBdRctGmmfc_AxT7Ke2yI Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:11:26 -0000 --001a113abfd88bd9f604f7959d52 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland wrote: > On 2014-04-21 22:36, Ladislav Lhotka wrote: > > > > On 21 Apr 2014, at 22:11, Per Hedeland wrote: > > > >> On 2014-04-21 21:52, Per Hedeland wrote: > >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: > >>>> > >>>> On 21 Apr 2014, at 15:13, Andy Bierman wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng > wrote: > >>>>> Hi all, > >>>>> I suggest add 'mandatory' to container to solve the problem > listed below: > >>>>> container a { > >>>>> leaf b; > >>>>> leaf c; > >>>>> } > >>>>> > >>>>> user can set b or set c or set b and c,but at least one is > assigned. > >>>>> > >>>>> > >>>>> > >>>>> You can use must-stmt: > >>>>> > >>>>> container a { > >>>>> must "b or c"; > >>>>> leaf b { ...} > >>>>> leaf c {...} > >>>>> } > >>>> > >>>> This doesn t work. If container a" doesn t exist in the data tree, > the must constraint doesn t apply (second paragraph in sec. 7.5.3). > >>> > >>> You seem to be assuming that the suggested "mandatory" on a container > >>> should be radically different from the existing "mandatory" on leafs > and > >>> choices - why? If container a doesn't exist, "mandatory" on e.g. leaf b > >>> has no effect - nor should the suggested "mandatory" on container a, > >>> meaning "b and/or c must be set", have any effect. Consider > >>> > >>> container p { > >>> presence "foo"; > >>> container a { > >>> mandatory true; // new suggestion > >>> leaf b {...} > >>> leaf c {...} > >>> } > >>> } > >>> > >>> If p doesn't exist, it would be completely unreasonable for the > >>> "mandatory" on a to force p into existence - and without that, > obviously > >>> neither b nor c could be set. At least it would be completely at odds > >>> with the semantics of the existing "mandatory" statement. > >>> > >>> Bottom line, "must" works just as well/bad as the new suggestion. > >> > >> Hm, or are you saying that, with > >> > >> container p { > >> presence "foo"; > >> container a { > >> must "b or c"; > >> leaf b {...} > >> leaf c {...} > >> } > >> } > >> > >> - the "must" wouldn't apply even if p existed? In that case there > > > > Sure, if a doesn t exist. > > > >> probably needs to be some clarification of what it means for a > >> np-container to "exist" for the purpose of "must" evaluation. Our > >> implementation certainly considers a to "exist" if p exists (regardless > >> of whether either of b and c exists) - and any other interpretation > >> seems bizarre to me, but maybe it isn't 110% clear from 6020& > > > > Bizarre? Sec. 7.5.8: > > > > If a container does not have a "presence" statement and the last > > child node is deleted, the NETCONF server MAY delete the container. > > The point is - and this *is* expressed in 6020 (7.5.1) - that the > "existence" of a np-container has no semantics. What you are saying (and > 6020 doesn't really contradict you) is that > > container p { > presence "foo"; > container a { > leaf b { > type ...; > mandatory true; > } > } > } > > and > > container p { > presence "foo"; > container a { > must "b"; > leaf b { > type ...; > } > } > } > > mean radically different things, and actually that the semantics of the > latter is basically undefined, since it would depend on whether > container a "happened to" exist, even though it can neither be created > nor deleted explicitly, and its existence isn't supposed to have any > semantics. > > I'm "pretty" sure this is not the intention of the authors. I seems what > is needed is a clarification (in 7.5.3) of when the "must" statements of > a np-container apply, similar to what is done for "mandatory" in 7.6.5. > > I am confused. These examples are different. In the first container 'p' definition, container 'a' is mandatory because NP-containers with mandatory child nodes are mandatory. In the 2nd definition, leaf 'b' must be present if its parent container 'a' is present, but the 'a' container is not itself mandatory. There is a hack (and also a demonstration of why this request may be reasonable after all): choice mandatory-np-container { mandatory true; container np-container { ... } } I just made a mandatory NP-container. Is this workaround good enough or should 'mandatory true' be allowed directly in the NP container? --Per > > Andy --001a113abfd88bd9f604f7959d52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland <= ;per@tail-f.com>= wrote:
    On 2014-04-21 22:36, Ladislav Lhotka wrote:<= br> >
    > On 21 Apr 2014, at 22:11, Per Hedeland <per@tail-f.com> wrote:
    >
    >> On 2014-04-21 21:52, Per Hedeland wrote:
    >>> On 2014-04-21 19:57, Ladislav Lhotka wrote:
    >>>>
    >>>> On 21 Apr 2014, at 15:13, Andy Bierman <andy@yumaworks.com> wrote:
    >>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng <fengchongllly@gmail.com> wrote:=
    >>>>> Hi all,
    >>>>> =A0 =A0I suggest add 'mandatory' to container = to solve the problem listed below:
    >>>>> =A0 =A0container a {
    >>>>> =A0 =A0 =A0 =A0 =A0leaf b;
    >>>>> =A0 =A0 =A0 =A0 =A0leaf c;
    >>>>> =A0 =A0}
    >>>>>
    >>>>> =A0 =A0user can set b or set c or set b and c,but at l= east one is assigned.
    >>>>>
    >>>>>
    >>>>>
    >>>>> You can use must-stmt:
    >>>>>
    >>>>> =A0 container a {
    >>>>> =A0 =A0 =A0must "b or c";
    >>>>> =A0 =A0 =A0leaf b { ...}
    >>>>> =A0 =A0 =A0leaf c {...}
    >>>>> =A0 }
    >>>>
    >>>> This doesn t work. If container =A0a" doesn t exist i= n the data tree, the must constraint doesn t apply (second paragraph in sec= . 7.5.3).
    >>>
    >>> You seem to be assuming that the suggested "mandatory&quo= t; on a container
    >>> should be radically different from the existing "mandator= y" on leafs and
    >>> choices - why? If container a doesn't exist, "mandato= ry" on e.g. leaf b
    >>> has no effect - nor should the suggested "mandatory"= on container a,
    >>> meaning "b and/or c must be set", have any effect. C= onsider
    >>>
    >>> =A0 container p {
    >>> =A0 =A0 presence "foo";
    >>> =A0 =A0 container a {
    >>> =A0 =A0 =A0 mandatory true; =A0// new suggestion
    >>> =A0 =A0 =A0 leaf b {...}
    >>> =A0 =A0 =A0 leaf c {...}
    >>> =A0 =A0 }
    >>> =A0 }
    >>>
    >>> If p doesn't exist, it would be completely unreasonable fo= r the
    >>> "mandatory" on a to force p into existence - and wit= hout that, obviously
    >>> neither b nor c could be set. At least it would be completely = at odds
    >>> with the semantics of the existing "mandatory" state= ment.
    >>>
    >>> Bottom line, "must" works just as well/bad as the ne= w suggestion.
    >>
    >> Hm, or are you saying that, with
    >>
    >> =A0 container p {
    >> =A0 =A0 presence "foo";
    >> =A0 =A0 container a {
    >> =A0 =A0 =A0 must "b or c";
    >> =A0 =A0 =A0 leaf b {...}
    >> =A0 =A0 =A0 leaf c {...}
    >> =A0 =A0 }
    >> =A0 }
    >>
    >> - the "must" wouldn't apply even if p existed? In th= at case there
    >
    > Sure, if =A0a =A0doesn t exist.
    >
    >> probably needs to be some clarification of what it means for a
    >> np-container to "exist" for the purpose of "must&qu= ot; evaluation. Our
    >> implementation certainly considers a to "exist" if p exi= sts (regardless
    >> of whether either of b and c exists) - and any other interpretatio= n
    >> seems bizarre to me, but maybe it isn't 110% clear from 6020&a= mp;
    >
    > Bizarre? Sec. 7.5.8:
    >
    > =A0 =A0If a container does not have a "presence" statement a= nd the last
    > =A0 =A0child node is deleted, the NETCONF server MAY delete the contai= ner.

    The point is - and this *is* expressed in 6020 (7.5.1) - that the
    "existence" of a np-container has no semantics. What you are sayi= ng (and
    6020 doesn't really contradict you) is that

    =A0 container p {
    =A0 =A0 presence "foo";
    =A0 =A0 container a {
    =A0 =A0 =A0 leaf b {
    =A0 =A0 =A0 =A0 type ...;
    =A0 =A0 =A0 =A0 mandatory true;
    =A0 =A0 =A0 }
    =A0 =A0 }
    =A0 }

    and

    =A0 container p {
    =A0 =A0 presence "foo";
    =A0 =A0 container a {
    =A0 =A0 =A0 must "b";
    =A0 =A0 =A0 leaf b {
    =A0 =A0 =A0 =A0 type ...;
    =A0 =A0 =A0 }
    =A0 =A0 }
    =A0 }

    mean radically different things, and actually that the semantics of the
    latter is basically undefined, since it would depend on whether
    container a "happened to" exist, even though it can neither be cr= eated
    nor deleted explicitly, and its existence isn't supposed to have any semantics.

    I'm "pretty" sure this is not the intention of the authors. I= seems what
    is needed is a clarification (in 7.5.3) of when the "must" statem= ents of
    a np-container apply, similar to what is done for "mandatory" in = 7.6.5.


    I am confused.
    These example= s are different.
    In the first container 'p' definition, c= ontainer 'a' is mandatory because
    NP-containers with mand= atory child nodes are mandatory.
    In the 2nd definition, leaf 'b' must be present if its parent = container 'a'
    is present, but the 'a' container i= s not itself mandatory.

    There is a hack (and also = a demonstration of why this request may be
    reasonable after all):

    =A0 =A0choice mandator= y-np-container {
    =A0 =A0 =A0 mandatory true;
    =A0 =A0 = =A0 container np-container { ... }
    =A0 =A0 }

    =
    I just made a mandatory NP-container.
    Is this workaround good enough or should 'mandatory true' be a= llowed
    directly in the NP container?


    --Per



    Andy

    --001a113abfd88bd9f604f7959d52-- From nobody Mon Apr 21 16:27:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E4E1A02BE for ; Mon, 21 Apr 2014 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awm_aDr6Tav2 for ; Mon, 21 Apr 2014 16:27:25 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA591A02B6 for ; Mon, 21 Apr 2014 16:27:25 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so4681353qgd.15 for ; Mon, 21 Apr 2014 16:27: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 :cc:content-type; bh=UEWhvu400hoTgQoh2OMnASDnGt8dw0U2e6mPA6ehAPY=; b=Q2wuN12LIzU0nwKa6HUHJXzzrp4yHbW+Utlp2ALyWa3yA3fLn2yQuXMFCKE88BSLmb vtlHcwdFuv2zyyYCeVYzMEDEtKYRxKa1TOa6EyZ2+T+wnkvBgHoAqVHmX8zqvLlGiv+T OnOFjuXIn5Ppc4RDLxLWs7kY20wezVAMhgNlVQoefVsV0RhjNPB+1dDMDdN946w4J2h8 U3/50/Cpp+wRI23zbhngVWbBKnu3RtU+DbIlFRXkNeEMncvt0uDtJhzx/LvyNdiFJhP1 W84zeNChSOjnWPFc0dRcuFJDyyjS/WcKzTlrgbFwJkN9WOWDqJms3A5GYF9T2WjBYR5n 3HFw== MIME-Version: 1.0 X-Received: by 10.140.18.173 with SMTP id 42mr3401624qgf.94.1398122840167; Mon, 21 Apr 2014 16:27:20 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Mon, 21 Apr 2014 16:27:20 -0700 (PDT) In-Reply-To: References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> Date: Tue, 22 Apr 2014 07:27:20 +0800 Message-ID: From: chong feng To: Andy Bierman Content-Type: multipart/alternative; boundary=001a11351cb23d9a6504f795d79e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OjvBsN-nzzeCdoSbRW3gXr7Y_YA Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:27:30 -0000 --001a11351cb23d9a6504f795d79e Content-Type: text/plain; charset=UTF-8 2014-04-22 7:11 GMT+08:00 Andy Bierman : > > > > On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland wrote: > >> On 2014-04-21 22:36, Ladislav Lhotka wrote: >> > >> > On 21 Apr 2014, at 22:11, Per Hedeland wrote: >> > >> >> On 2014-04-21 21:52, Per Hedeland wrote: >> >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: >> >>>> >> >>>> On 21 Apr 2014, at 15:13, Andy Bierman wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng < >> fengchongllly@gmail.com> wrote: >> >>>>> Hi all, >> >>>>> I suggest add 'mandatory' to container to solve the problem >> listed below: >> >>>>> container a { >> >>>>> leaf b; >> >>>>> leaf c; >> >>>>> } >> >>>>> >> >>>>> user can set b or set c or set b and c,but at least one is >> assigned. >> >>>>> >> >>>>> >> >>>>> >> >>>>> You can use must-stmt: >> >>>>> >> >>>>> container a { >> >>>>> must "b or c"; >> >>>>> leaf b { ...} >> >>>>> leaf c {...} >> >>>>> } >> >>>> >> >>>> This doesn t work. If container a" doesn t exist in the data tree, >> the must constraint doesn t apply (second paragraph in sec. 7.5.3). >> >>> >> >>> You seem to be assuming that the suggested "mandatory" on a container >> >>> should be radically different from the existing "mandatory" on leafs >> and >> >>> choices - why? If container a doesn't exist, "mandatory" on e.g. leaf >> b >> >>> has no effect - nor should the suggested "mandatory" on container a, >> >>> meaning "b and/or c must be set", have any effect. Consider >> >>> >> >>> container p { >> >>> presence "foo"; >> >>> container a { >> >>> mandatory true; // new suggestion >> >>> leaf b {...} >> >>> leaf c {...} >> >>> } >> >>> } >> >>> >> >>> If p doesn't exist, it would be completely unreasonable for the >> >>> "mandatory" on a to force p into existence - and without that, >> obviously >> >>> neither b nor c could be set. At least it would be completely at odds >> >>> with the semantics of the existing "mandatory" statement. >> >>> >> >>> Bottom line, "must" works just as well/bad as the new suggestion. >> >> >> >> Hm, or are you saying that, with >> >> >> >> container p { >> >> presence "foo"; >> >> container a { >> >> must "b or c"; >> >> leaf b {...} >> >> leaf c {...} >> >> } >> >> } >> >> >> >> - the "must" wouldn't apply even if p existed? In that case there >> > >> > Sure, if a doesn t exist. >> > >> >> probably needs to be some clarification of what it means for a >> >> np-container to "exist" for the purpose of "must" evaluation. Our >> >> implementation certainly considers a to "exist" if p exists (regardless >> >> of whether either of b and c exists) - and any other interpretation >> >> seems bizarre to me, but maybe it isn't 110% clear from 6020& >> > >> > Bizarre? Sec. 7.5.8: >> > >> > If a container does not have a "presence" statement and the last >> > child node is deleted, the NETCONF server MAY delete the container. >> >> The point is - and this *is* expressed in 6020 (7.5.1) - that the >> "existence" of a np-container has no semantics. What you are saying (and >> 6020 doesn't really contradict you) is that >> >> container p { >> presence "foo"; >> container a { >> leaf b { >> type ...; >> mandatory true; >> } >> } >> } >> >> and >> >> container p { >> presence "foo"; >> container a { >> must "b"; >> leaf b { >> type ...; >> } >> } >> } >> >> mean radically different things, and actually that the semantics of the >> latter is basically undefined, since it would depend on whether >> container a "happened to" exist, even though it can neither be created >> nor deleted explicitly, and its existence isn't supposed to have any >> semantics. >> >> I'm "pretty" sure this is not the intention of the authors. I seems what >> is needed is a clarification (in 7.5.3) of when the "must" statements of >> a np-container apply, similar to what is done for "mandatory" in 7.6.5. >> >> > I am confused. > These examples are different. > In the first container 'p' definition, container 'a' is mandatory because > NP-containers with mandatory child nodes are mandatory. > In the 2nd definition, leaf 'b' must be present if its parent container 'a' > is present, but the 'a' container is not itself mandatory. > > There is a hack (and also a demonstration of why this request may be > reasonable after all): > > choice mandatory-np-container { > mandatory true; > container np-container { ... } > } > > I just made a mandatory NP-container. > Is this workaround good enough or should 'mandatory true' be allowed > directly in the NP container? > > I think add 'mandatory true' directly is simple on this situation. > > > --Per >> >> > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11351cb23d9a6504f795d79e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    2014-04-22 7:11 GMT+08:00 Andy Bierman <andy@yumaworks.com>= ;:



    On Mon, Apr 2= 1, 2014 at 2:08 PM, Per Hedeland <per@tail-f.com> wrote:
    On 2014-04-21 22:36, Ladislav Lhotka wrote:<= br> >
    > On 21 Apr 2014, at 22:11, Per Hedeland <per@tail-f.com> wrote:
    >
    >> On 2014-04-21 21:52, Per Hedeland wrote:
    >>> On 2014-04-21 19:57, Ladislav Lhotka wrote:
    >>>>
    >>>> On 21 Apr 2014, at 15:13, Andy Bierman <andy@yumaworks.com> wrote:<= br> >>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng <fengchongllly@gmail.= com> wrote:
    >>>>> Hi all,
    >>>>> =C2=A0 =C2=A0I suggest add 'mandatory' to cont= ainer to solve the problem listed below:
    >>>>> =C2=A0 =C2=A0container a {
    >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf b;
    >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf c;
    >>>>> =C2=A0 =C2=A0}
    >>>>>
    >>>>> =C2=A0 =C2=A0user can set b or set c or set b and c,bu= t at least one is assigned.
    >>>>>
    >>>>>
    >>>>>
    >>>>> You can use must-stmt:
    >>>>>
    >>>>> =C2=A0 container a {
    >>>>> =C2=A0 =C2=A0 =C2=A0must "b or c";
    >>>>> =C2=A0 =C2=A0 =C2=A0leaf b { ...}
    >>>>> =C2=A0 =C2=A0 =C2=A0leaf c {...}
    >>>>> =C2=A0 }
    >>>>
    >>>> This doesn t work. If container =C2=A0a" doesn t exis= t in the data tree, the must constraint doesn t apply (second paragraph in = sec. 7.5.3).
    >>>
    >>> You seem to be assuming that the suggested "mandatory&quo= t; on a container
    >>> should be radically different from the existing "mandator= y" on leafs and
    >>> choices - why? If container a doesn't exist, "mandato= ry" on e.g. leaf b
    >>> has no effect - nor should the suggested "mandatory"= on container a,
    >>> meaning "b and/or c must be set", have any effect. C= onsider
    >>>
    >>> =C2=A0 container p {
    >>> =C2=A0 =C2=A0 presence "foo";
    >>> =C2=A0 =C2=A0 container a {
    >>> =C2=A0 =C2=A0 =C2=A0 mandatory true; =C2=A0// new suggestion >>> =C2=A0 =C2=A0 =C2=A0 leaf b {...}
    >>> =C2=A0 =C2=A0 =C2=A0 leaf c {...}
    >>> =C2=A0 =C2=A0 }
    >>> =C2=A0 }
    >>>
    >>> If p doesn't exist, it would be completely unreasonable fo= r the
    >>> "mandatory" on a to force p into existence - and wit= hout that, obviously
    >>> neither b nor c could be set. At least it would be completely = at odds
    >>> with the semantics of the existing "mandatory" state= ment.
    >>>
    >>> Bottom line, "must" works just as well/bad as the ne= w suggestion.
    >>
    >> Hm, or are you saying that, with
    >>
    >> =C2=A0 container p {
    >> =C2=A0 =C2=A0 presence "foo";
    >> =C2=A0 =C2=A0 container a {
    >> =C2=A0 =C2=A0 =C2=A0 must "b or c";
    >> =C2=A0 =C2=A0 =C2=A0 leaf b {...}
    >> =C2=A0 =C2=A0 =C2=A0 leaf c {...}
    >> =C2=A0 =C2=A0 }
    >> =C2=A0 }
    >>
    >> - the "must" wouldn't apply even if p existed? In th= at case there
    >
    > Sure, if =C2=A0a =C2=A0doesn t exist.
    >
    >> probably needs to be some clarification of what it means for a
    >> np-container to "exist" for the purpose of "must&qu= ot; evaluation. Our
    >> implementation certainly considers a to "exist" if p exi= sts (regardless
    >> of whether either of b and c exists) - and any other interpretatio= n
    >> seems bizarre to me, but maybe it isn't 110% clear from 6020&a= mp;
    >
    > Bizarre? Sec. 7.5.8:
    >
    > =C2=A0 =C2=A0If a container does not have a "presence" state= ment and the last
    > =C2=A0 =C2=A0child node is deleted, the NETCONF server MAY delete the = container.

    The point is - and this *is* expressed in 6020 (7.5.1) - that the
    "existence" of a np-container has no semantics. What you are sayi= ng (and
    6020 doesn't really contradict you) is that

    =C2=A0 container p {
    =C2=A0 =C2=A0 presence "foo";
    =C2=A0 =C2=A0 container a {
    =C2=A0 =C2=A0 =C2=A0 leaf b {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 type ...;
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
    =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 }
    =C2=A0 }

    and

    =C2=A0 container p {
    =C2=A0 =C2=A0 presence "foo";
    =C2=A0 =C2=A0 container a {
    =C2=A0 =C2=A0 =C2=A0 must "b";
    =C2=A0 =C2=A0 =C2=A0 leaf b {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 type ...;
    =C2=A0 =C2=A0 =C2=A0 }
    =C2=A0 =C2=A0 }
    =C2=A0 }

    mean radically different things, and actually that the semantics of the
    latter is basically undefined, since it would depend on whether
    container a "happened to" exist, even though it can neither be cr= eated
    nor deleted explicitly, and its existence isn't supposed to have any semantics.

    I'm "pretty" sure this is not the intention of the authors. I= seems what
    is needed is a clarification (in 7.5.3) of when the "must" statem= ents of
    a np-container apply, similar to what is done for "mandatory" in = 7.6.5.


    I am confused.
    T= hese examples are different.
    In the first container 'p' d= efinition, container 'a' is mandatory because
    NP-containe= rs with mandatory child nodes are mandatory.
    In the 2nd definition, leaf 'b' must be present if its parent = container 'a'
    is present, but the 'a' container i= s not itself mandatory.

    There is a hack (and also = a demonstration of why this request may be
    reasonable after all):

    =C2=A0 =C2=A0choice ma= ndatory-np-container {
    =C2=A0 =C2=A0 =C2=A0 mandatory true;
    =
    =C2=A0 =C2=A0 =C2=A0 container np-container { ... }
    =C2=A0 = =C2=A0 }

    I just made a mandatory NP-container.
    Is this workaround good enough or should 'mandatory true' be a= llowed
    directly in the NP container?

    I think add 'mandatory true' directly i= s simple on this situation.=C2=A0
    =


    --Per



    Andy

    =

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod


    --001a11351cb23d9a6504f795d79e-- From nobody Mon Apr 21 16:37:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5371A031F for ; Mon, 21 Apr 2014 16:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oKBKgeHzRNZ for ; Mon, 21 Apr 2014 16:37:35 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id BC0811A031D for ; Mon, 21 Apr 2014 16:37:34 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id x13so4741762qcv.29 for ; Mon, 21 Apr 2014 16:37:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/dAOqzNiMoNH/KKWRZtB8yD7fkqsPEiQ5ciD8S3iiHE=; b=WGKZEMFSLCMMwdCFWu5HnUWTxHXpWWX7nmb/5jTkILwVcCfN4zg4DTScgrWd4fzJor 893PTJGWZrg+sqlpuOvQAowQimgR1lB0IeImTSUR/1NFUi15Me3wtPe9bSnbI7+QpAHR c4xcyDzQ9g6hBYXeC5P2L/RtZv3ss3Tx6avTG+8NKBzousgoA/TeyQ0YkxWb/Slv0bfb 61TD3Mkuddc+3Si4w7lfJyZDyfN3lzsgEUO+pvDVmeTMQPjVu9FOwh6puaFlJhqcK7Py eItJDl7ofwcIq7BSwH4rsH9yfNrp/YUN9tB9L6sIdoBEFRbF4vT8RZ2MWRbfM68ztxl7 GZaw== X-Gm-Message-State: ALoCoQlqC6UTvc1dqRwJHHN6EQ6PS9IWCPbNGqy6TzKeyd0u3YS1xDCeP4QkMGI86rH+a7L5rRWT MIME-Version: 1.0 X-Received: by 10.140.27.212 with SMTP id 78mr47504712qgx.18.1398123449394; Mon, 21 Apr 2014 16:37:29 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 16:37:29 -0700 (PDT) In-Reply-To: References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> Date: Mon, 21 Apr 2014 16:37:29 -0700 Message-ID: From: Andy Bierman To: chong feng Content-Type: multipart/alternative; boundary=001a11c14d668e17d304f795fb70 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ifbAG1FxqyasmiwG4XP1tqCC04I Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:37:39 -0000 --001a11c14d668e17d304f795fb70 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 21, 2014 at 4:27 PM, chong feng wrote: > > > > 2014-04-22 7:11 GMT+08:00 Andy Bierman : > >> >> >> >> On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland wrote: >> >>> On 2014-04-21 22:36, Ladislav Lhotka wrote: >>> > >>> > On 21 Apr 2014, at 22:11, Per Hedeland wrote: >>> > >>> >> On 2014-04-21 21:52, Per Hedeland wrote: >>> >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: >>> >>>> >>> >>>> On 21 Apr 2014, at 15:13, Andy Bierman wrote: >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng < >>> fengchongllly@gmail.com> wrote: >>> >>>>> Hi all, >>> >>>>> I suggest add 'mandatory' to container to solve the problem >>> listed below: >>> >>>>> container a { >>> >>>>> leaf b; >>> >>>>> leaf c; >>> >>>>> } >>> >>>>> >>> >>>>> user can set b or set c or set b and c,but at least one is >>> assigned. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> You can use must-stmt: >>> >>>>> >>> >>>>> container a { >>> >>>>> must "b or c"; >>> >>>>> leaf b { ...} >>> >>>>> leaf c {...} >>> >>>>> } >>> >>>> >>> >>>> This doesn t work. If container a" doesn t exist in the data tree, >>> the must constraint doesn t apply (second paragraph in sec. 7.5.3). >>> >>> >>> >>> You seem to be assuming that the suggested "mandatory" on a container >>> >>> should be radically different from the existing "mandatory" on leafs >>> and >>> >>> choices - why? If container a doesn't exist, "mandatory" on e.g. >>> leaf b >>> >>> has no effect - nor should the suggested "mandatory" on container a, >>> >>> meaning "b and/or c must be set", have any effect. Consider >>> >>> >>> >>> container p { >>> >>> presence "foo"; >>> >>> container a { >>> >>> mandatory true; // new suggestion >>> >>> leaf b {...} >>> >>> leaf c {...} >>> >>> } >>> >>> } >>> >>> >>> >>> If p doesn't exist, it would be completely unreasonable for the >>> >>> "mandatory" on a to force p into existence - and without that, >>> obviously >>> >>> neither b nor c could be set. At least it would be completely at odds >>> >>> with the semantics of the existing "mandatory" statement. >>> >>> >>> >>> Bottom line, "must" works just as well/bad as the new suggestion. >>> >> >>> >> Hm, or are you saying that, with >>> >> >>> >> container p { >>> >> presence "foo"; >>> >> container a { >>> >> must "b or c"; >>> >> leaf b {...} >>> >> leaf c {...} >>> >> } >>> >> } >>> >> >>> >> - the "must" wouldn't apply even if p existed? In that case there >>> > >>> > Sure, if a doesn t exist. >>> > >>> >> probably needs to be some clarification of what it means for a >>> >> np-container to "exist" for the purpose of "must" evaluation. Our >>> >> implementation certainly considers a to "exist" if p exists >>> (regardless >>> >> of whether either of b and c exists) - and any other interpretation >>> >> seems bizarre to me, but maybe it isn't 110% clear from 6020& >>> > >>> > Bizarre? Sec. 7.5.8: >>> > >>> > If a container does not have a "presence" statement and the last >>> > child node is deleted, the NETCONF server MAY delete the container. >>> >>> The point is - and this *is* expressed in 6020 (7.5.1) - that the >>> "existence" of a np-container has no semantics. What you are saying (and >>> 6020 doesn't really contradict you) is that >>> >>> container p { >>> presence "foo"; >>> container a { >>> leaf b { >>> type ...; >>> mandatory true; >>> } >>> } >>> } >>> >>> and >>> >>> container p { >>> presence "foo"; >>> container a { >>> must "b"; >>> leaf b { >>> type ...; >>> } >>> } >>> } >>> >>> mean radically different things, and actually that the semantics of the >>> latter is basically undefined, since it would depend on whether >>> container a "happened to" exist, even though it can neither be created >>> nor deleted explicitly, and its existence isn't supposed to have any >>> semantics. >>> >>> I'm "pretty" sure this is not the intention of the authors. I seems what >>> is needed is a clarification (in 7.5.3) of when the "must" statements of >>> a np-container apply, similar to what is done for "mandatory" in 7.6.5. >>> >>> >> I am confused. >> These examples are different. >> In the first container 'p' definition, container 'a' is mandatory because >> NP-containers with mandatory child nodes are mandatory. >> In the 2nd definition, leaf 'b' must be present if its parent container >> 'a' >> is present, but the 'a' container is not itself mandatory. >> >> There is a hack (and also a demonstration of why this request may be >> reasonable after all): >> >> choice mandatory-np-container { >> mandatory true; >> container np-container { ... } >> } >> >> I just made a mandatory NP-container. >> Is this workaround good enough or should 'mandatory true' be allowed >> directly in the NP container? >> >> I think add 'mandatory true' directly is simple on this situation. > I think you are right. (Martin, add it to the list please). BTW, does sec 10 allow any data node to be converted into a choice-of-1 in a future revision? o Any set of data definition nodes may be replaced with another set of syntactically and semantically equivalent nodes. For example, a set of leafs may be replaced by a uses of a grouping with the same leafs. E.g.: container foo { ... } changed to choice foo { container foo { ... } } Is this legal because of the clause in sec. 10 cited above? >> >> --Per >>> >>> >> >> Andy >> >> Andy --001a11c14d668e17d304f795fb70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 21, 2014 at 4:27 PM, chong feng <<= a href=3D"mailto:fengchongllly@gmail.com" target=3D"_blank">fengchongllly@g= mail.com> wrote:



    2014-04-22 7:11 GMT+08:00 Andy Bierman <andy@yumaworks.com>= :



    On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland &= lt;per@tail-f.com&g= t; wrote:
    On 2014-04-21 22:36, Ladislav Lhotka wrote:
    >
    > On 21 Apr 2014, at 22:11, Per Hedeland <per@tail-f.com> wrote:
    >
    >> On 2014-04-21 21:52, Per Hedeland wrote:
    >>> On 2014-04-21 19:57, Ladislav Lhotka wrote:
    >>>>
    >>>> On 21 Apr 2014, at 15:13, Andy Bierman <andy@yumaworks.com> wrote:<= br> >>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng <fengchongllly@gmail.= com> wrote:
    >>>>> Hi all,
    >>>>> =A0 =A0I suggest add 'mandatory' to container = to solve the problem listed below:
    >>>>> =A0 =A0container a {
    >>>>> =A0 =A0 =A0 =A0 =A0leaf b;
    >>>>> =A0 =A0 =A0 =A0 =A0leaf c;
    >>>>> =A0 =A0}
    >>>>>
    >>>>> =A0 =A0user can set b or set c or set b and c,but at l= east one is assigned.
    >>>>>
    >>>>>
    >>>>>
    >>>>> You can use must-stmt:
    >>>>>
    >>>>> =A0 container a {
    >>>>> =A0 =A0 =A0must "b or c";
    >>>>> =A0 =A0 =A0leaf b { ...}
    >>>>> =A0 =A0 =A0leaf c {...}
    >>>>> =A0 }
    >>>>
    >>>> This doesn t work. If container =A0a" doesn t exist i= n the data tree, the must constraint doesn t apply (second paragraph in sec= . 7.5.3).
    >>>
    >>> You seem to be assuming that the suggested "mandatory&quo= t; on a container
    >>> should be radically different from the existing "mandator= y" on leafs and
    >>> choices - why? If container a doesn't exist, "mandato= ry" on e.g. leaf b
    >>> has no effect - nor should the suggested "mandatory"= on container a,
    >>> meaning "b and/or c must be set", have any effect. C= onsider
    >>>
    >>> =A0 container p {
    >>> =A0 =A0 presence "foo";
    >>> =A0 =A0 container a {
    >>> =A0 =A0 =A0 mandatory true; =A0// new suggestion
    >>> =A0 =A0 =A0 leaf b {...}
    >>> =A0 =A0 =A0 leaf c {...}
    >>> =A0 =A0 }
    >>> =A0 }
    >>>
    >>> If p doesn't exist, it would be completely unreasonable fo= r the
    >>> "mandatory" on a to force p into existence - and wit= hout that, obviously
    >>> neither b nor c could be set. At least it would be completely = at odds
    >>> with the semantics of the existing "mandatory" state= ment.
    >>>
    >>> Bottom line, "must" works just as well/bad as the ne= w suggestion.
    >>
    >> Hm, or are you saying that, with
    >>
    >> =A0 container p {
    >> =A0 =A0 presence "foo";
    >> =A0 =A0 container a {
    >> =A0 =A0 =A0 must "b or c";
    >> =A0 =A0 =A0 leaf b {...}
    >> =A0 =A0 =A0 leaf c {...}
    >> =A0 =A0 }
    >> =A0 }
    >>
    >> - the "must" wouldn't apply even if p existed? In th= at case there
    >
    > Sure, if =A0a =A0doesn t exist.
    >
    >> probably needs to be some clarification of what it means for a
    >> np-container to "exist" for the purpose of "must&qu= ot; evaluation. Our
    >> implementation certainly considers a to "exist" if p exi= sts (regardless
    >> of whether either of b and c exists) - and any other interpretatio= n
    >> seems bizarre to me, but maybe it isn't 110% clear from 6020&a= mp;
    >
    > Bizarre? Sec. 7.5.8:
    >
    > =A0 =A0If a container does not have a "presence" statement a= nd the last
    > =A0 =A0child node is deleted, the NETCONF server MAY delete the contai= ner.

    The point is - and this *is* expressed in 6020 (7.5.1) - that the
    "existence" of a np-container has no semantics. What you are sayi= ng (and
    6020 doesn't really contradict you) is that

    =A0 container p {
    =A0 =A0 presence "foo";
    =A0 =A0 container a {
    =A0 =A0 =A0 leaf b {
    =A0 =A0 =A0 =A0 type ...;
    =A0 =A0 =A0 =A0 mandatory true;
    =A0 =A0 =A0 }
    =A0 =A0 }
    =A0 }

    and

    =A0 container p {
    =A0 =A0 presence "foo";
    =A0 =A0 container a {
    =A0 =A0 =A0 must "b";
    =A0 =A0 =A0 leaf b {
    =A0 =A0 =A0 =A0 type ...;
    =A0 =A0 =A0 }
    =A0 =A0 }
    =A0 }

    mean radically different things, and actually that the semantics of the
    latter is basically undefined, since it would depend on whether
    container a "happened to" exist, even though it can neither be cr= eated
    nor deleted explicitly, and its existence isn't supposed to have any semantics.

    I'm "pretty" sure this is not the intention of the authors. I= seems what
    is needed is a clarification (in 7.5.3) of when the "must" statem= ents of
    a np-container apply, similar to what is done for "mandatory" in = 7.6.5.


    I am confused.
    T= hese examples are different.
    In the first container 'p' d= efinition, container 'a' is mandatory because
    NP-containe= rs with mandatory child nodes are mandatory.
    In the 2nd definition, leaf 'b' must be present if its parent = container 'a'
    is present, but the 'a' container i= s not itself mandatory.

    There is a hack (and also = a demonstration of why this request may be
    reasonable after all):

    =A0 =A0choice mandator= y-np-container {
    =A0 =A0 =A0 mandatory true;
    =A0 =A0 = =A0 container np-container { ... }
    =A0 =A0 }

    =
    I just made a mandatory NP-container.
    Is this workaround good enough or should 'mandatory true' be a= llowed
    directly in the NP container?

    I think add 'mandatory true' directly i= s simple on this situation.=A0

    I think you are right.

    (Martin, add it to the list please).

    =
    BTW, does sec 10 allow any data node
    to be converted i= nto a choice-of-1 in a future revision?

       o  Any set of data definition nodes may be replaced w=
    ith another set
          of syntactically and semantically equivalent nodes.  For example,
          a set of leafs may be replaced by a uses of a grouping with the
          same leafs.
    E.g.:
    =A0 =A0 container foo { ... }

    chang= ed to

    =A0 =A0 choice foo {
    =A0 =A0 =A0 =A0container foo { ... }
    =A0 =A0 =A0}

    Is this legal because of the clause in sec. 10 cited ab= ove?


    =A0 =A0 =A0



    --Per



    Andy



    Andy

    =A0
    --001a11c14d668e17d304f795fb70-- From nobody Mon Apr 21 23:46:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9634F1A00BF for ; Mon, 21 Apr 2014 23:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSJSbAzqHEEC for ; Mon, 21 Apr 2014 23:46:29 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2EC1A00B6 for ; Mon, 21 Apr 2014 23:46:28 -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 B9864476C4E; Tue, 22 Apr 2014 08:46:22 +0200 (CEST) Date: Tue, 22 Apr 2014 08:46:22 +0200 (CEST) Message-Id: <20140422.084622.570055904764562321.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EeyhWcMydc60ltJKY-E4hLDJXe8 Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 06:46:33 -0000 Andy Bierman wrote: > On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland wrote: > > > On 2014-04-21 22:36, Ladislav Lhotka wrote: > > > > > > On 21 Apr 2014, at 22:11, Per Hedeland wrote: > > > > > >> On 2014-04-21 21:52, Per Hedeland wrote: > > >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: > > >>>> > > >>>> On 21 Apr 2014, at 15:13, Andy Bierman wrote: > > >>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng > > wrote: > > >>>>> Hi all, > > >>>>> I suggest add 'mandatory' to container to solve the problem > > listed below: > > >>>>> container a { > > >>>>> leaf b; > > >>>>> leaf c; > > >>>>> } > > >>>>> > > >>>>> user can set b or set c or set b and c,but at least one is > > assigned. > > >>>>> > > >>>>> > > >>>>> > > >>>>> You can use must-stmt: > > >>>>> > > >>>>> container a { > > >>>>> must "b or c"; > > >>>>> leaf b { ...} > > >>>>> leaf c {...} > > >>>>> } > > >>>> > > >>>> This doesn t work. If container a" doesn t exist in the data tree, > > the must constraint doesn t apply (second paragraph in sec. 7.5.3). > > >>> > > >>> You seem to be assuming that the suggested "mandatory" on a container > > >>> should be radically different from the existing "mandatory" on leafs > > and > > >>> choices - why? If container a doesn't exist, "mandatory" on e.g. leaf b > > >>> has no effect - nor should the suggested "mandatory" on container a, > > >>> meaning "b and/or c must be set", have any effect. Consider > > >>> > > >>> container p { > > >>> presence "foo"; > > >>> container a { > > >>> mandatory true; // new suggestion > > >>> leaf b {...} > > >>> leaf c {...} > > >>> } > > >>> } > > >>> > > >>> If p doesn't exist, it would be completely unreasonable for the > > >>> "mandatory" on a to force p into existence - and without that, > > obviously > > >>> neither b nor c could be set. At least it would be completely at odds > > >>> with the semantics of the existing "mandatory" statement. > > >>> > > >>> Bottom line, "must" works just as well/bad as the new suggestion. > > >> > > >> Hm, or are you saying that, with > > >> > > >> container p { > > >> presence "foo"; > > >> container a { > > >> must "b or c"; > > >> leaf b {...} > > >> leaf c {...} > > >> } > > >> } > > >> > > >> - the "must" wouldn't apply even if p existed? In that case there > > > > > > Sure, if a doesn t exist. > > > > > >> probably needs to be some clarification of what it means for a > > >> np-container to "exist" for the purpose of "must" evaluation. Our > > >> implementation certainly considers a to "exist" if p exists (regardless > > >> of whether either of b and c exists) - and any other interpretation > > >> seems bizarre to me, but maybe it isn't 110% clear from 6020& > > > > > > Bizarre? Sec. 7.5.8: > > > > > > If a container does not have a "presence" statement and the last > > > child node is deleted, the NETCONF server MAY delete the container. > > > > The point is - and this *is* expressed in 6020 (7.5.1) - that the > > "existence" of a np-container has no semantics. What you are saying (and > > 6020 doesn't really contradict you) is that > > > > container p { > > presence "foo"; > > container a { > > leaf b { > > type ...; > > mandatory true; > > } > > } > > } > > > > and > > > > container p { > > presence "foo"; > > container a { > > must "b"; > > leaf b { > > type ...; > > } > > } > > } > > > > mean radically different things, and actually that the semantics of the > > latter is basically undefined, since it would depend on whether > > container a "happened to" exist, even though it can neither be created > > nor deleted explicitly, and its existence isn't supposed to have any > > semantics. > > > > I'm "pretty" sure this is not the intention of the authors. I seems what > > is needed is a clarification (in 7.5.3) of when the "must" statements of > > a np-container apply, similar to what is done for "mandatory" in 7.6.5. Yes, I agree with this. Since the NP-container itself has no semantics, so it cannot change the meaning of must or mandatory leafs. Thus, the requested functionality can be done today with "must". > I am confused. > These examples are different. > In the first container 'p' definition, container 'a' is mandatory because > NP-containers with mandatory child nodes are mandatory. > In the 2nd definition, leaf 'b' must be present if its parent container 'a' > is present, but the 'a' container is not itself mandatory. > > There is a hack (and also a demonstration of why this request may be > reasonable after all): > > choice mandatory-np-container { > mandatory true; > container np-container { ... } > } > > I just made a mandatory NP-container. > Is this workaround good enough or should 'mandatory true' be allowed > directly in the NP container? Having a "mandatory NP container" in itself makes no sense. Since the NP container doesn't have any semantics, what does it mean to make it mandatory? I don't think we should allow "mandatory" in an NP container just b/c this hack exists. /martin From nobody Mon Apr 21 23:53:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D231A00D4 for ; Mon, 21 Apr 2014 23:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0DJjxuuhFQj for ; Mon, 21 Apr 2014 23:53:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 62B851A00BF for ; Mon, 21 Apr 2014 23:53: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 C3A81476C4E; Tue, 22 Apr 2014 08:53:18 +0200 (CEST) Date: Tue, 22 Apr 2014 08:53:18 +0200 (CEST) Message-Id: <20140422.085318.597843036399942082.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OoHMO85E_PwV78NMtV2g50M1J9I Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 06:53:29 -0000 Andy Bierman wrote: > (Martin, add it to the list please). Done. Y38. /martin From nobody Tue Apr 22 00:01:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02C1A00E4; Tue, 22 Apr 2014 00:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd4n58xJ0Saz; Tue, 22 Apr 2014 00:01:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 866381A00CB; Tue, 22 Apr 2014 00:01:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422070145.11789.38017.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 00:01:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tkwjjQMqBUoPlxoptpAg64Dd_jc Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 07:01:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : JSON Encoding of Data Modeled with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-json-00.txt Pages : 20 Date : 2014-04-21 Abstract: This document defines rules for representing configuration and state data defined using YANG as JSON text. It does so by specifying a procedure for translating the subset of YANG-compatible XML documents to JSON text, and vice versa. A JSON encoding of XML attributes is also defined so as to allow for including metadata in JSON documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 22 00:12:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907A31A00DD for ; Tue, 22 Apr 2014 00:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hgPVWvFVqZ8 for ; Tue, 22 Apr 2014 00:12:47 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4E45C1A00C3 for ; Tue, 22 Apr 2014 00:12:47 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x3so4922620qcv.40 for ; Tue, 22 Apr 2014 00:12:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RIAdPpf/Eg3T2H5Xf4YmbMdBEo05uMBoqQ7TiqwtIPs=; b=LWAXe9ldpb59H1CgRxugDc8ahpn8gZx25ovTNQqcGvtLd2P2e3iutLHOnaECsfmjIV 7LaGmai9pTDq67QtwZ7L6+RtdMCko/gEtwdOdGyf92owRR6cYEb9GGsYDqRZlbzyp9pH lacff+YjLqyXQ1sXmF3tJSyRQ0VUznrKCadCfZ9TH+zpzpbqzMAwDgNRPIWfIBWx1FO/ AqD0yhXaJ0Q8muAVIsR0wNZ9HjyXyfXIuv/79oZFfNO3ZvzmqEdcAm4ibYxjKZupM58H JzFoTgjjhAOorWmRHBSb3qPIuArvWJ7jn/LKW60E7afQIWJpczBEhsWG9GLOezrIpIsz kdRw== X-Gm-Message-State: ALoCoQkxYWYkw6wa4EVF4cj8pJnU3faA4J5l3cvKIl9ympXTd/UrtkcMQjHV3La1uGsCGWIR167O MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr9357107qge.91.1398150761887; Tue, 22 Apr 2014 00:12:41 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 22 Apr 2014 00:12:41 -0700 (PDT) In-Reply-To: <20140422.084622.570055904764562321.mbj@tail-f.com> References: <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> <20140422.084622.570055904764562321.mbj@tail-f.com> Date: Tue, 22 Apr 2014 00:12:41 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1134f2be814c0f04f79c5768 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MGJLQEphO7gTV4BK7lfa4W7N3Hs Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 07:12:52 -0000 --001a1134f2be814c0f04f79c5768 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 21, 2014 at 11:46 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland wrote: > > > > > On 2014-04-21 22:36, Ladislav Lhotka wrote: > > > > > > > > On 21 Apr 2014, at 22:11, Per Hedeland wrote: > > > > > > > >> On 2014-04-21 21:52, Per Hedeland wrote: > > > >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: > > > >>>> > > > >>>> On 21 Apr 2014, at 15:13, Andy Bierman > wrote: > > > >>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng < > fengchongllly@gmail.com> > > > wrote: > > > >>>>> Hi all, > > > >>>>> I suggest add 'mandatory' to container to solve the problem > > > listed below: > > > >>>>> container a { > > > >>>>> leaf b; > > > >>>>> leaf c; > > > >>>>> } > > > >>>>> > > > >>>>> user can set b or set c or set b and c,but at least one is > > > assigned. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> You can use must-stmt: > > > >>>>> > > > >>>>> container a { > > > >>>>> must "b or c"; > > > >>>>> leaf b { ...} > > > >>>>> leaf c {...} > > > >>>>> } > > > >>>> > > > >>>> This doesn t work. If container a" doesn t exist in the data > tree, > > > the must constraint doesn t apply (second paragraph in sec. 7.5.3). > > > >>> > > > >>> You seem to be assuming that the suggested "mandatory" on a > container > > > >>> should be radically different from the existing "mandatory" on > leafs > > > and > > > >>> choices - why? If container a doesn't exist, "mandatory" on e.g. > leaf b > > > >>> has no effect - nor should the suggested "mandatory" on container > a, > > > >>> meaning "b and/or c must be set", have any effect. Consider > > > >>> > > > >>> container p { > > > >>> presence "foo"; > > > >>> container a { > > > >>> mandatory true; // new suggestion > > > >>> leaf b {...} > > > >>> leaf c {...} > > > >>> } > > > >>> } > > > >>> > > > >>> If p doesn't exist, it would be completely unreasonable for the > > > >>> "mandatory" on a to force p into existence - and without that, > > > obviously > > > >>> neither b nor c could be set. At least it would be completely at > odds > > > >>> with the semantics of the existing "mandatory" statement. > > > >>> > > > >>> Bottom line, "must" works just as well/bad as the new suggestion. > > > >> > > > >> Hm, or are you saying that, with > > > >> > > > >> container p { > > > >> presence "foo"; > > > >> container a { > > > >> must "b or c"; > > > >> leaf b {...} > > > >> leaf c {...} > > > >> } > > > >> } > > > >> > > > >> - the "must" wouldn't apply even if p existed? In that case there > > > > > > > > Sure, if a doesn t exist. > > > > > > > >> probably needs to be some clarification of what it means for a > > > >> np-container to "exist" for the purpose of "must" evaluation. Our > > > >> implementation certainly considers a to "exist" if p exists > (regardless > > > >> of whether either of b and c exists) - and any other interpretation > > > >> seems bizarre to me, but maybe it isn't 110% clear from 6020& > > > > > > > > Bizarre? Sec. 7.5.8: > > > > > > > > If a container does not have a "presence" statement and the last > > > > child node is deleted, the NETCONF server MAY delete the > container. > > > > > > The point is - and this *is* expressed in 6020 (7.5.1) - that the > > > "existence" of a np-container has no semantics. What you are saying > (and > > > 6020 doesn't really contradict you) is that > > > > > > container p { > > > presence "foo"; > > > container a { > > > leaf b { > > > type ...; > > > mandatory true; > > > } > > > } > > > } > > > > > > and > > > > > > container p { > > > presence "foo"; > > > container a { > > > must "b"; > > > leaf b { > > > type ...; > > > } > > > } > > > } > > > > > > mean radically different things, and actually that the semantics of the > > > latter is basically undefined, since it would depend on whether > > > container a "happened to" exist, even though it can neither be created > > > nor deleted explicitly, and its existence isn't supposed to have any > > > semantics. > > > > > > I'm "pretty" sure this is not the intention of the authors. I seems > what > > > is needed is a clarification (in 7.5.3) of when the "must" statements > of > > > a np-container apply, similar to what is done for "mandatory" in 7.6.5. > > Yes, I agree with this. > > Since the NP-container itself has no semantics, so it cannot change > the meaning of must or mandatory leafs. > > Thus, the requested functionality can be done today with "must". > > > > I am confused. > > These examples are different. > > In the first container 'p' definition, container 'a' is mandatory because > > NP-containers with mandatory child nodes are mandatory. > > In the 2nd definition, leaf 'b' must be present if its parent container > 'a' > > is present, but the 'a' container is not itself mandatory. > > > > There is a hack (and also a demonstration of why this request may be > > reasonable after all): > > > > choice mandatory-np-container { > > mandatory true; > > container np-container { ... } > > } > > > > I just made a mandatory NP-container. > > Is this workaround good enough or should 'mandatory true' be allowed > > directly in the NP container? > > Having a "mandatory NP container" in itself makes no sense. Since the > NP container doesn't have any semantics, what does it mean to make it > mandatory? > > not so sure about this transparency argument container-stmt = container-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) *(must-stmt stmtsep) [presence-stmt stmtsep] [config-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] *((typedef-stmt / grouping-stmt) stmtsep) *(data-def-stmt stmtsep) "}") when-stmt and if-feature-stmt make all the child nodes conditional must-stmt could be viewed in the same way -- convenient way to apply I don't think we should allow "mandatory" in an NP container just b/c > this hack exists. > > > /martin > --001a1134f2be814c0f04f79c5768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 21, 2014 at 11:46 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
    Andy Bierman <and= y@yumaworks.com> wrote:
    > On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland <per@tail-f.com> wrote:
    >
    > > On 2014-04-21 22:36, Ladislav Lhotka wrote:
    > > >
    > > > On 21 Apr 2014, at 22:11, Per Hedeland <per@tail-f.com> wrote:
    > > >
    > > >> On 2014-04-21 21:52, Per Hedeland wrote:
    > > >>> On 2014-04-21 19:57, Ladislav Lhotka wrote:
    > > >>>>
    > > >>>> On 21 Apr 2014, at 15:13, Andy Bierman <andy@yumaworks.com> wrote:
    > > >>>>
    > > >>>>>
    > > >>>>>
    > > >>>>>
    > > >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng = <fengchongllly@gmail.com&= gt;
    > > wrote:
    > > >>>>> Hi all,
    > > >>>>> =A0 =A0I suggest add 'mandatory' to = container to solve the problem
    > > listed below:
    > > >>>>> =A0 =A0container a {
    > > >>>>> =A0 =A0 =A0 =A0 =A0leaf b;
    > > >>>>> =A0 =A0 =A0 =A0 =A0leaf c;
    > > >>>>> =A0 =A0}
    > > >>>>>
    > > >>>>> =A0 =A0user can set b or set c or set b and = c,but at least one is
    > > assigned.
    > > >>>>>
    > > >>>>>
    > > >>>>>
    > > >>>>> You can use must-stmt:
    > > >>>>>
    > > >>>>> =A0 container a {
    > > >>>>> =A0 =A0 =A0must "b or c";
    > > >>>>> =A0 =A0 =A0leaf b { ...}
    > > >>>>> =A0 =A0 =A0leaf c {...}
    > > >>>>> =A0 }
    > > >>>>
    > > >>>> This doesn t work. If container =A0a" doesn= t exist in the data tree,
    > > the must constraint doesn t apply (second paragraph in sec. 7.5.3= ).
    > > >>>
    > > >>> You seem to be assuming that the suggested "man= datory" on a container
    > > >>> should be radically different from the existing &quo= t;mandatory" on leafs
    > > and
    > > >>> choices - why? If container a doesn't exist, &qu= ot;mandatory" on e.g. leaf b
    > > >>> has no effect - nor should the suggested "manda= tory" on container a,
    > > >>> meaning "b and/or c must be set", have any= effect. Consider
    > > >>>
    > > >>> =A0 container p {
    > > >>> =A0 =A0 presence "foo";
    > > >>> =A0 =A0 container a {
    > > >>> =A0 =A0 =A0 mandatory true; =A0// new suggestion
    > > >>> =A0 =A0 =A0 leaf b {...}
    > > >>> =A0 =A0 =A0 leaf c {...}
    > > >>> =A0 =A0 }
    > > >>> =A0 }
    > > >>>
    > > >>> If p doesn't exist, it would be completely unrea= sonable for the
    > > >>> "mandatory" on a to force p into existence= - and without that,
    > > obviously
    > > >>> neither b nor c could be set. At least it would be c= ompletely at odds
    > > >>> with the semantics of the existing "mandatory&q= uot; statement.
    > > >>>
    > > >>> Bottom line, "must" works just as well/bad= as the new suggestion.
    > > >>
    > > >> Hm, or are you saying that, with
    > > >>
    > > >> =A0 container p {
    > > >> =A0 =A0 presence "foo";
    > > >> =A0 =A0 container a {
    > > >> =A0 =A0 =A0 must "b or c";
    > > >> =A0 =A0 =A0 leaf b {...}
    > > >> =A0 =A0 =A0 leaf c {...}
    > > >> =A0 =A0 }
    > > >> =A0 }
    > > >>
    > > >> - the "must" wouldn't apply even if p exis= ted? In that case there
    > > >
    > > > Sure, if =A0a =A0doesn t exist.
    > > >
    > > >> probably needs to be some clarification of what it means= for a
    > > >> np-container to "exist" for the purpose of &qu= ot;must" evaluation. Our
    > > >> implementation certainly considers a to "exist"= ; if p exists (regardless
    > > >> of whether either of b and c exists) - and any other int= erpretation
    > > >> seems bizarre to me, but maybe it isn't 110% clear f= rom 6020&
    > > >
    > > > Bizarre? Sec. 7.5.8:
    > > >
    > > > =A0 =A0If a container does not have a "presence" s= tatement and the last
    > > > =A0 =A0child node is deleted, the NETCONF server MAY delete = the container.
    > >
    > > The point is - and this *is* expressed in 6020 (7.5.1) - that the=
    > > "existence" of a np-container has no semantics. What yo= u are saying (and
    > > 6020 doesn't really contradict you) is that
    > >
    > > =A0 container p {
    > > =A0 =A0 presence "foo";
    > > =A0 =A0 container a {
    > > =A0 =A0 =A0 leaf b {
    > > =A0 =A0 =A0 =A0 type ...;
    > > =A0 =A0 =A0 =A0 mandatory true;
    > > =A0 =A0 =A0 }
    > > =A0 =A0 }
    > > =A0 }
    > >
    > > and
    > >
    > > =A0 container p {
    > > =A0 =A0 presence "foo";
    > > =A0 =A0 container a {
    > > =A0 =A0 =A0 must "b";
    > > =A0 =A0 =A0 leaf b {
    > > =A0 =A0 =A0 =A0 type ...;
    > > =A0 =A0 =A0 }
    > > =A0 =A0 }
    > > =A0 }
    > >
    > > mean radically different things, and actually that the semantics = of the
    > > latter is basically undefined, since it would depend on whether > > container a "happened to" exist, even though it can nei= ther be created
    > > nor deleted explicitly, and its existence isn't supposed to h= ave any
    > > semantics.
    > >
    > > I'm "pretty" sure this is not the intention of the = authors. I seems what
    > > is needed is a clarification (in 7.5.3) of when the "must&qu= ot; statements of
    > > a np-container apply, similar to what is done for "mandatory= " in 7.6.5.

    Yes, I agree with this.

    Since the NP-container itself has no semantics, so it cannot change
    the meaning of must or mandatory leafs.

    Thus, the requested functionality can be done today with "must".<= br>

    > I am confused.
    > These examples are different.
    > In the first container 'p' definition, container 'a' i= s mandatory because
    > NP-containers with mandatory child nodes are mandatory.
    > In the 2nd definition, leaf 'b' must be present if its parent = container 'a'
    > is present, but the 'a' container is not itself mandatory.
    >
    > There is a hack (and also a demonstration of why this request may be > reasonable after all):
    >
    > =A0 =A0choice mandatory-np-container {
    > =A0 =A0 =A0 mandatory true;
    > =A0 =A0 =A0 container np-container { ... }
    > =A0 =A0 }
    >
    > I just made a mandatory NP-container.
    > Is this workaround good enough or should 'mandatory true' be a= llowed
    > directly in the NP container?

    Having a "mandatory NP container" in itself makes no sense. =A0Si= nce the
    NP container doesn't have any semantics, what does it mean to make it mandatory?


    not so sure about this t= ransparency argument

     container-stmt      =3D conta=
    iner-keyword sep identifier-arg-str optsep
                             (";" /
                              "{" stmtsep
                                  ;; these stmts can appear in any order
                                  [when-stmt stmtsep]
                                  *(if-feature-stmt stmtsep)
                                  *(must-stmt stmtsep)
                                  [presence-stmt stmtsep]
                                  [config-stmt stmtsep]
                                  [status-stmt stmtsep]
                                  [description-stmt stmtsep]
                                  [reference-stmt stmtsep]
                                  *((typedef-stmt /
                                     grouping-stmt) stmtsep)
                                  *(data-def-stmt stmtsep)
                              "}")
    
    

    =
    when-stmt and if-feature-stmt make all=
     the child nodes conditional
    must-stmt could be viewed in the same w=
    ay -- convenient way to apply

    I don't think we should allow "mandatory" in an NP container = just b/c
    this hack exists.


    /martin

    --001a1134f2be814c0f04f79c5768-- From nobody Tue Apr 22 00:17:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33861A0028 for ; Tue, 22 Apr 2014 00:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMgN3j3RQkLI for ; Tue, 22 Apr 2014 00:17:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3A23D1A007A for ; Tue, 22 Apr 2014 00:17:08 -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 2CB81476C4E; Tue, 22 Apr 2014 09:17:02 +0200 (CEST) Date: Tue, 22 Apr 2014 09:17:01 +0200 (CEST) Message-Id: <20140422.091701.504992998997147886.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140422.084622.570055904764562321.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SH9lrBmFQBifQpuzmkshb9IFAlU Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 07:17:13 -0000 Andy Bierman wrote: > On Mon, Apr 21, 2014 at 11:46 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland wrote: > > > > > > > On 2014-04-21 22:36, Ladislav Lhotka wrote: > > > > > > > > > > On 21 Apr 2014, at 22:11, Per Hedeland wrote: > > > > > > > > > >> On 2014-04-21 21:52, Per Hedeland wrote: > > > > >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: > > > > >>>> > > > > >>>> On 21 Apr 2014, at 15:13, Andy Bierman > > wrote: > > > > >>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng < > > fengchongllly@gmail.com> > > > > wrote: > > > > >>>>> Hi all, > > > > >>>>> I suggest add 'mandatory' to container to solve the problem > > > > listed below: > > > > >>>>> container a { > > > > >>>>> leaf b; > > > > >>>>> leaf c; > > > > >>>>> } > > > > >>>>> > > > > >>>>> user can set b or set c or set b and c,but at least one is > > > > assigned. > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> You can use must-stmt: > > > > >>>>> > > > > >>>>> container a { > > > > >>>>> must "b or c"; > > > > >>>>> leaf b { ...} > > > > >>>>> leaf c {...} > > > > >>>>> } > > > > >>>> > > > > >>>> This doesn t work. If container a" doesn t exist in the data > > tree, > > > > the must constraint doesn t apply (second paragraph in sec. 7.5.3). > > > > >>> > > > > >>> You seem to be assuming that the suggested "mandatory" on a > > container > > > > >>> should be radically different from the existing "mandatory" on > > leafs > > > > and > > > > >>> choices - why? If container a doesn't exist, "mandatory" on e.g. > > leaf b > > > > >>> has no effect - nor should the suggested "mandatory" on container > > a, > > > > >>> meaning "b and/or c must be set", have any effect. Consider > > > > >>> > > > > >>> container p { > > > > >>> presence "foo"; > > > > >>> container a { > > > > >>> mandatory true; // new suggestion > > > > >>> leaf b {...} > > > > >>> leaf c {...} > > > > >>> } > > > > >>> } > > > > >>> > > > > >>> If p doesn't exist, it would be completely unreasonable for the > > > > >>> "mandatory" on a to force p into existence - and without that, > > > > obviously > > > > >>> neither b nor c could be set. At least it would be completely at > > odds > > > > >>> with the semantics of the existing "mandatory" statement. > > > > >>> > > > > >>> Bottom line, "must" works just as well/bad as the new suggestion. > > > > >> > > > > >> Hm, or are you saying that, with > > > > >> > > > > >> container p { > > > > >> presence "foo"; > > > > >> container a { > > > > >> must "b or c"; > > > > >> leaf b {...} > > > > >> leaf c {...} > > > > >> } > > > > >> } > > > > >> > > > > >> - the "must" wouldn't apply even if p existed? In that case there > > > > > > > > > > Sure, if a doesn t exist. > > > > > > > > > >> probably needs to be some clarification of what it means for a > > > > >> np-container to "exist" for the purpose of "must" evaluation. Our > > > > >> implementation certainly considers a to "exist" if p exists > > (regardless > > > > >> of whether either of b and c exists) - and any other interpretation > > > > >> seems bizarre to me, but maybe it isn't 110% clear from 6020& > > > > > > > > > > Bizarre? Sec. 7.5.8: > > > > > > > > > > If a container does not have a "presence" statement and the last > > > > > child node is deleted, the NETCONF server MAY delete the > > container. > > > > > > > > The point is - and this *is* expressed in 6020 (7.5.1) - that the > > > > "existence" of a np-container has no semantics. What you are saying > > (and > > > > 6020 doesn't really contradict you) is that > > > > > > > > container p { > > > > presence "foo"; > > > > container a { > > > > leaf b { > > > > type ...; > > > > mandatory true; > > > > } > > > > } > > > > } > > > > > > > > and > > > > > > > > container p { > > > > presence "foo"; > > > > container a { > > > > must "b"; > > > > leaf b { > > > > type ...; > > > > } > > > > } > > > > } > > > > > > > > mean radically different things, and actually that the semantics of the > > > > latter is basically undefined, since it would depend on whether > > > > container a "happened to" exist, even though it can neither be created > > > > nor deleted explicitly, and its existence isn't supposed to have any > > > > semantics. > > > > > > > > I'm "pretty" sure this is not the intention of the authors. I seems > > what > > > > is needed is a clarification (in 7.5.3) of when the "must" statements > > of > > > > a np-container apply, similar to what is done for "mandatory" in 7.6.5. > > > > Yes, I agree with this. > > > > Since the NP-container itself has no semantics, so it cannot change > > the meaning of must or mandatory leafs. > > > > Thus, the requested functionality can be done today with "must". > > > > > > > I am confused. > > > These examples are different. > > > In the first container 'p' definition, container 'a' is mandatory because > > > NP-containers with mandatory child nodes are mandatory. > > > In the 2nd definition, leaf 'b' must be present if its parent container > > 'a' > > > is present, but the 'a' container is not itself mandatory. > > > > > > There is a hack (and also a demonstration of why this request may be > > > reasonable after all): > > > > > > choice mandatory-np-container { > > > mandatory true; > > > container np-container { ... } > > > } > > > > > > I just made a mandatory NP-container. > > > Is this workaround good enough or should 'mandatory true' be allowed > > > directly in the NP container? > > > > Having a "mandatory NP container" in itself makes no sense. Since the > > NP container doesn't have any semantics, what does it mean to make it > > mandatory? > > > > > not so sure about this transparency argument > > container-stmt = container-keyword sep identifier-arg-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [when-stmt stmtsep] > *(if-feature-stmt stmtsep) > *(must-stmt stmtsep) > [presence-stmt stmtsep] > [config-stmt stmtsep] > [status-stmt stmtsep] > [description-stmt stmtsep] > [reference-stmt stmtsep] > *((typedef-stmt / > grouping-stmt) stmtsep) > *(data-def-stmt stmtsep) > "}") > > > > when-stmt and if-feature-stmt make all the child nodes conditional They do that also if you move them from the NP-container into the subnodes. /martin From nobody Tue Apr 22 01:05:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492E51A0125 for ; Tue, 22 Apr 2014 01:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2BGwqOMW3iw for ; Tue, 22 Apr 2014 01:05: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 C8BDD1A013E for ; Tue, 22 Apr 2014 01:05:10 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D5EE813F686 for ; Tue, 22 Apr 2014 10:05:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398153902; bh=bqO3yxdIZtMZuvm3b6QVhL41DT52sS+ubTSFGzNhG/Y=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=DlfM0UgpDvJ7s5wnHiea9JoX+aB7jG3h7wcDQpCSi+OqwUfB8g9HhCuKvZqZXh3sJ BK4vljrEssZe3AbK9ewWrk/pMesst5bOHn2yTaXc8eWg50Fd/lgMX4/LMk2WNV+oP0 ynwDFsBkCko5RsSgvX3W3yOyEjLn4e0j9pmA3dOU= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Apr 2014 10:05:02 +0200 References: <20140422070145.11789.38017.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <886D341F-2F6C-42AC-952B-BBE3CBF2F5FB@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zXpFcdfuz2z6DwwDZ6vzwZf_8Yg Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 08:05:16 -0000 Hi, I made the YANG-JSON draft into a WG item. The most significant change = in the contents is sec. 4 that attempts to define an encoding for = attributes. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-00.txt > Date: 22 Apr 2014 09:01:45 GMT+2 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : JSON Encoding of Data Modeled with YANG > Author : Ladislav Lhotka > Filename : draft-ietf-netmod-yang-json-00.txt > Pages : 20 > Date : 2014-04-21 >=20 > Abstract: > This document defines rules for representing configuration and state > data defined using YANG as JSON text. It does so by specifying a > procedure for translating the subset of YANG-compatible XML = documents > to JSON text, and vice versa. A JSON encoding of XML attributes is > also defined so as to allow for including metadata in JSON = documents. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 22 01:20:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E4C1A013D for ; Tue, 22 Apr 2014 01:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e082QCls5QDn for ; Tue, 22 Apr 2014 01:20:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C651A1A0147 for ; Tue, 22 Apr 2014 01:20:29 -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 CDCCA39419D; Tue, 22 Apr 2014 10:20:22 +0200 (CEST) Date: Tue, 22 Apr 2014 10:20:22 +0200 (CEST) Message-Id: <20140422.102022.2013098191154721023.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <886D341F-2F6C-42AC-952B-BBE3CBF2F5FB@nic.cz> References: <20140422070145.11789.38017.idtracker@ietfa.amsl.com> <886D341F-2F6C-42AC-952B-BBE3CBF2F5FB@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ov0doa0GQDrKZxpEpIQ9hw84Wkw Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 08:20:34 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > I made the YANG-JSON draft into a WG item. The most significant change > in the contents is sec. 4 that attempts to define an encoding for > attributes. Thank you; I think this new section makes this encoding much more useful. One nit: s/nil/null/ in section 4. One question: In section 4 you write: The encoding of attributes as specified above has the following two limitations: o Mapping of namespaces of XML attributes is undefined. o Attribute values can only be strings, other data types are not supported. Is the last bullet really a limitation? XML attributes are always encoded as "strings", and this JSON encoding just mimics that. Or put differently, are there any XML attributes that cannot be mapped, because of this? Maybe we should also note that xmlns attributes are NOT mapped? /martin From nobody Tue Apr 22 02:15:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195761A0187 for ; Tue, 22 Apr 2014 02:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVoLU1-xzWMk for ; Tue, 22 Apr 2014 02:15:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2258A1A017D for ; Tue, 22 Apr 2014 02:15:49 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 882ED1405A4; Tue, 22 Apr 2014 11:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398158143; bh=WxbpebDI+QqDWbIG5n4JohLuBNkh8szr4oFb6uhhTkM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HxD4Uiy384MVQ3QoKcIAwks0EKcn/+sEspFfhG1PxBh9zrcQzRe0RA6WNGqY/jwoJ /rNWwOrub/ZH5Y1fB6yvRhLgcDaR0RdHE6p4eCAnnktQPlG8lW5AEljX5YlavYf1UY DdMkPU/JZYUDRBYJZO6Tel3FhEY9/8Qs6TYNayK8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140422.102022.2013098191154721023.mbj@tail-f.com> Date: Tue, 22 Apr 2014 11:15:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140422070145.11789.38017.idtracker@ietfa.amsl.com> <886D341F-2F6C-42AC-952B-BBE3CBF2F5FB@nic.cz> <20140422.102022.2013098191154721023.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RNGuvcwMnzoS-QqEROXKFA3HTj8 Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 09:15:56 -0000 On 22 Apr 2014, at 10:20, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> I made the YANG-JSON draft into a WG item. The most significant = change >> in the contents is sec. 4 that attempts to define an encoding for >> attributes. >=20 > Thank you; I think this new section makes this encoding much more > useful. >=20 > One nit: s/nil/null/ in section 4. Oh yes. Lisp is closer to my heart than JavaScript. :-) >=20 > One question: >=20 > In section 4 you write: >=20 > The encoding of attributes as specified above has the following two > limitations: >=20 > o Mapping of namespaces of XML attributes is undefined. >=20 > o Attribute values can only be strings, other data types are not > supported. >=20 > Is the last bullet really a limitation? XML attributes are always > encoded as "strings", and this JSON encoding just mimics that. So is element content. Schema languages allow to define other types for = attributes, and if we add the =91attribute=92 statement in YANG 1.1 (see = issue Y33), I can imagine it would also define a type, and this could be = reflected in JSON.=20 >=20 > Or put differently, are there any XML attributes that cannot be > mapped, because of this? >=20 >=20 > Maybe we should also note that xmlns attributes are NOT mapped? Maybe, although it probably cannot cause any harm if they are mapped. Thanks, Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 22 03:02:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305FC1A01D1 for ; Tue, 22 Apr 2014 03:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv7W9JulQFSJ for ; Tue, 22 Apr 2014 03:02:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8931A014E for ; Tue, 22 Apr 2014 03:02:34 -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 D4BE7574001; Tue, 22 Apr 2014 12:02:27 +0200 (CEST) Date: Tue, 22 Apr 2014 12:02:27 +0200 (CEST) Message-Id: <20140422.120227.1634510515642921743.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <886D341F-2F6C-42AC-952B-BBE3CBF2F5FB@nic.cz> <20140422.102022.2013098191154721023.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lrBUtkuvcuiuC4EfH6NqmIexrVU Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 10:02:39 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDIyIEFwciAy MDE0LCBhdCAxMDoyMCwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBPbmUgcXVlc3Rpb246DQo+ID4gDQo+ID4gIEluIHNlY3Rpb24gNCB5b3Ugd3JpdGU6 DQo+ID4gDQo+ID4gICBUaGUgZW5jb2Rpbmcgb2YgYXR0cmlidXRlcyBhcyBzcGVjaWZpZWQgYWJv dmUgaGFzIHRoZSBmb2xsb3dpbmcgdHdvDQo+ID4gICBsaW1pdGF0aW9uczoNCj4gPiANCj4gPiAg IG8gIE1hcHBpbmcgb2YgbmFtZXNwYWNlcyBvZiBYTUwgYXR0cmlidXRlcyBpcyB1bmRlZmluZWQu DQo+ID4gDQo+ID4gICBvICBBdHRyaWJ1dGUgdmFsdWVzIGNhbiBvbmx5IGJlIHN0cmluZ3MsIG90 aGVyIGRhdGEgdHlwZXMgYXJlIG5vdA0KPiA+ICAgICAgc3VwcG9ydGVkLg0KPiA+IA0KPiA+IElz IHRoZSBsYXN0IGJ1bGxldCByZWFsbHkgYSBsaW1pdGF0aW9uPyAgWE1MIGF0dHJpYnV0ZXMgYXJl IGFsd2F5cw0KPiA+IGVuY29kZWQgYXMgInN0cmluZ3MiLCBhbmQgdGhpcyBKU09OIGVuY29kaW5n IGp1c3QgbWltaWNzIHRoYXQuDQo+IA0KPiBTbyBpcyBlbGVtZW50IGNvbnRlbnQuIFNjaGVtYSBs YW5ndWFnZXMgYWxsb3cgdG8gZGVmaW5lIG90aGVyIHR5cGVzDQo+IGZvciBhdHRyaWJ1dGVzLCBh bmQgaWYgd2UgYWRkIHRoZSDigJhhdHRyaWJ1dGXigJkgc3RhdGVtZW50IGluIFlBTkcgMS4xDQo+ IChzZWUgaXNzdWUgWTMzKSwgSSBjYW4gaW1hZ2luZSBpdCB3b3VsZCBhbHNvIGRlZmluZSBhIHR5 cGUsIGFuZCB0aGlzDQo+IGNvdWxkIGJlIHJlZmxlY3RlZCBpbiBKU09OLg0KDQpSaWdodC4gIEJ1 dCB0aGVuIHRoZSBsaW1pdGF0aW9uIGlzIHRoYXQgYXR0cmlidXRlIHZhbHVlcyBhcmUgYWx3YXlz DQplbmNvZGVkIGFzIHN0cmluZ3MsIHJlZ2FyZGxlc3Mgb2YgdGhlIHVuZGVybHlpbmcgdHlwZS4g IEkuZS4sIHRoZXkNCl9hcmVfIHN1cHBvcnRlZCwgYnV0IGVuY29kZWQgYXMgc3RyaW5ncy4NCg0K DQo+ID4gT3IgcHV0IGRpZmZlcmVudGx5LCBhcmUgdGhlcmUgYW55IFhNTCBhdHRyaWJ1dGVzIHRo YXQgY2Fubm90IGJlDQo+ID4gbWFwcGVkLCBiZWNhdXNlIG9mIHRoaXM/DQo+ID4gDQo+ID4gDQo+ ID4gTWF5YmUgd2Ugc2hvdWxkIGFsc28gbm90ZSB0aGF0IHhtbG5zIGF0dHJpYnV0ZXMgYXJlIE5P VCBtYXBwZWQ/DQo+IA0KPiBNYXliZSwgYWx0aG91Z2ggaXQgcHJvYmFibHkgY2Fubm90IGNhdXNl IGFueSBoYXJtIGlmIHRoZXkgYXJlIG1hcHBlZC4NCg0KVHJ1ZTsgYnV0IGl0IHdvdWxkIGJlIG5v aXNlLg0KDQoNCi9tYXJ0aW4NCg== From nobody Tue Apr 22 05:30:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845531A0400 for ; Tue, 22 Apr 2014 05:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcePxAxuRekN for ; Tue, 22 Apr 2014 05:29:56 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE21A03FF for ; Tue, 22 Apr 2014 05:29:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8C648540798; Tue, 22 Apr 2014 14:29:48 +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 v7TQeoSkvcBD; Tue, 22 Apr 2014 14:29:43 +0200 (CEST) Received: from localhost (cst-prg-111-6.cust.vodafone.cz [46.135.111.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E3081540087; Tue, 22 Apr 2014 14:29:38 +0200 (CEST) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <535588B7.3080401@tail-f.com> References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 22 Apr 2014 14:29:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7gTavQ-XA36VFGOG9VglZpQXou0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:30:01 -0000 Per Hedeland writes: > > The point is - and this *is* expressed in 6020 (7.5.1) - that the > "existence" of a np-container has no semantics. What you are saying (and They may not have semantics from YANG's viewpoint but they are still nodes in the data tree that either exist or not, and as such influence the context for XPath evaluation. > 6020 doesn't really contradict you) is that > > container p { > presence "foo"; > container a { > leaf b { > type ...; > mandatory true; > } > } > } > > and > > container p { > presence "foo"; > container a { > must "b"; > leaf b { > type ...; > } > } > } > > mean radically different things, and actually that the semantics of the They do mean different things! The "mandatory" statement is a schema constraint, and sec. 3.1 then explicitly states that "a" is a mandatory node. In contrast, "must" is a semantic constraint that (as any XPath expression) has to be evaluated in the well-defined context of a concrete XML instance document. And it is then significant whether the expression's context node exists or not. It has been a recurring issue in the previous discussions about "must" and especially "when" that the meaning of XPath expressions is being sort of shifted to the schema, under the assumption that an implementation can (temporarily) insert dummy nodes here and there in the instance document, and that the gentle implementor will figure out the intentions of the data modeller. I think this is a wrong approach that can lead to interoperability problems and race conditions. > latter is basically undefined, since it would depend on whether > container a "happened to" exist, even though it can neither be created > nor deleted explicitly, and its existence isn't supposed to have any > semantics. > > I'm "pretty" sure this is not the intention of the authors. I seems what > is needed is a clarification (in 7.5.3) of when the "must" statements of > a np-container apply, similar to what is done for "mandatory" in 7.6.5. To support your view, what's essentially needed is to state that NP-containers are always part of the default contents. Lada > > --Per -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 22 05:33:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6D31A0409 for ; Tue, 22 Apr 2014 05:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmOFWitM3qz3 for ; Tue, 22 Apr 2014 05:33:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 51AD91A0401 for ; Tue, 22 Apr 2014 05:33:18 -0700 (PDT) Received: from [192.168.42.250] (cst-prg-111-6.cust.vodafone.cz [46.135.111.6]) by mail.nic.cz (Postfix) with ESMTPSA id 392FC13F9C5; Tue, 22 Apr 2014 14:33:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398169992; bh=vBF9sQUz3Tu1v4TliIcoL4nYTEkehnaNKMLx5A2N2Yk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=i2Vj6qG1ez6X7+tHH5uGu1sy13q736YIxBdg7pr1gGjOUOG8x+r++SG7oMa+YAwQu 1hd1Lni1aVGWH90Apvrlq2gQpcEJ3EIB/Aoh7FIDjT3bwEBKI5t2WIet/SDBBERoBB JrABUXU87TdiZFpLU3ijoC8+JTUo2RqgKmau/ewY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140422.120227.1634510515642921743.mbj@tail-f.com> Date: Tue, 22 Apr 2014 14:32:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <886D341F-2F6C-42AC-952B-BBE3CBF2F5FB@nic.cz> <20140422.102022.2013098191154721023.mbj@tail-f.com> <20140422.120227.1634510515642921743.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XfWtwVFDkjXHxNtgZ8AsxRrWpUE Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:33:23 -0000 On 22 Apr 2014, at 12:02, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 22 Apr 2014, at 10:20, Martin Bjorklund wrote: >>=20 >>> One question: >>>=20 >>> In section 4 you write: >>>=20 >>> The encoding of attributes as specified above has the following two >>> limitations: >>>=20 >>> o Mapping of namespaces of XML attributes is undefined. >>>=20 >>> o Attribute values can only be strings, other data types are not >>> supported. >>>=20 >>> Is the last bullet really a limitation? XML attributes are always >>> encoded as "strings", and this JSON encoding just mimics that. >>=20 >> So is element content. Schema languages allow to define other types >> for attributes, and if we add the =91attribute=92 statement in YANG = 1.1 >> (see issue Y33), I can imagine it would also define a type, and this >> could be reflected in JSON. >=20 > Right. But then the limitation is that attribute values are always > encoded as strings, regardless of the underlying type. I.e., they > _are_ supported, but encoded as strings. Yes. >=20 >=20 >>> Or put differently, are there any XML attributes that cannot be >>> mapped, because of this? >>>=20 >>>=20 >>> Maybe we should also note that xmlns attributes are NOT mapped? >>=20 >> Maybe, although it probably cannot cause any harm if they are mapped. >=20 > True; but it would be noise. OK, I=92d suggest to put an appropriate =93SHOULD NOT=94 to the text. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 22 08:29:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9272A1A065E for ; Tue, 22 Apr 2014 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3yXBwWcT6it for ; Tue, 22 Apr 2014 08:28:56 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id AFFF91A0229 for ; Tue, 22 Apr 2014 08:28:56 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ih12so5097633qab.23 for ; Tue, 22 Apr 2014 08:28:51 -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 :cc:content-type; bh=bVdo18CQ4XVTgi0tw69jYvuojwo1oijTBBMmZ0Dhs+o=; b=wCOQmJU6IOwLn4UcQB34nZOr0Ygbe/wxDd9z00/UJDRFbFxsGLc+tiZQTDT7fCA/dt hLDYfpXjfgoQjMN+dKCoaAgFO4gOtA0d6bJOlWhGFfK+KRirP8dyCMQRZaW5N0IrXBVH +8ZTAx70P4WF/Q2V9/CTRpFFJC87YuXY2l/A8omiEONXbU2UxYSCO3SHv5huFdjGAgkN pclsyucAdIr8gXQZMo46/7+egCMqfWkbdic7PDbCOp8NXBJfr5Lnz+pg0QWWjFE8DBiH oNSwX8CmCXRUlhp9DbRZwXH+HA3EE7E/lMBk8OMq9fdXyP8GJSDXjtdN113oZdgqUfZT r/fw== MIME-Version: 1.0 X-Received: by 10.229.221.194 with SMTP id id2mr49402671qcb.5.1398180531087; Tue, 22 Apr 2014 08:28:51 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Tue, 22 Apr 2014 08:28:51 -0700 (PDT) In-Reply-To: <20140422.084622.570055904764562321.mbj@tail-f.com> References: <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> <20140422.084622.570055904764562321.mbj@tail-f.com> Date: Tue, 22 Apr 2014 23:28:51 +0800 Message-ID: From: chong feng To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11343920e32d7304f7a3457d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U1YFrQIk77Cfod0j28R0vmxn5Dg Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 15:29:01 -0000 --001a11343920e32d7304f7a3457d Content-Type: text/plain; charset=UTF-8 2014-04-22 14:46 GMT+08:00 Martin Bjorklund : > Andy Bierman wrote: > > On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland wrote: > > > > > On 2014-04-21 22:36, Ladislav Lhotka wrote: > > > > > > > > On 21 Apr 2014, at 22:11, Per Hedeland wrote: > > > > > > > >> On 2014-04-21 21:52, Per Hedeland wrote: > > > >>> On 2014-04-21 19:57, Ladislav Lhotka wrote: > > > >>>> > > > >>>> On 21 Apr 2014, at 15:13, Andy Bierman > wrote: > > > >>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng < > fengchongllly@gmail.com> > > > wrote: > > > >>>>> Hi all, > > > >>>>> I suggest add 'mandatory' to container to solve the problem > > > listed below: > > > >>>>> container a { > > > >>>>> leaf b; > > > >>>>> leaf c; > > > >>>>> } > > > >>>>> > > > >>>>> user can set b or set c or set b and c,but at least one is > > > assigned. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> You can use must-stmt: > > > >>>>> > > > >>>>> container a { > > > >>>>> must "b or c"; > > > >>>>> leaf b { ...} > > > >>>>> leaf c {...} > > > >>>>> } > > > >>>> > > > >>>> This doesn t work. If container a" doesn t exist in the data > tree, > > > the must constraint doesn t apply (second paragraph in sec. 7.5.3). > > > >>> > > > >>> You seem to be assuming that the suggested "mandatory" on a > container > > > >>> should be radically different from the existing "mandatory" on > leafs > > > and > > > >>> choices - why? If container a doesn't exist, "mandatory" on e.g. > leaf b > > > >>> has no effect - nor should the suggested "mandatory" on container > a, > > > >>> meaning "b and/or c must be set", have any effect. Consider > > > >>> > > > >>> container p { > > > >>> presence "foo"; > > > >>> container a { > > > >>> mandatory true; // new suggestion > > > >>> leaf b {...} > > > >>> leaf c {...} > > > >>> } > > > >>> } > > > >>> > > > >>> If p doesn't exist, it would be completely unreasonable for the > > > >>> "mandatory" on a to force p into existence - and without that, > > > obviously > > > >>> neither b nor c could be set. At least it would be completely at > odds > > > >>> with the semantics of the existing "mandatory" statement. > > > >>> > > > >>> Bottom line, "must" works just as well/bad as the new suggestion. > > > >> > > > >> Hm, or are you saying that, with > > > >> > > > >> container p { > > > >> presence "foo"; > > > >> container a { > > > >> must "b or c"; > > > >> leaf b {...} > > > >> leaf c {...} > > > >> } > > > >> } > > > >> > > > >> - the "must" wouldn't apply even if p existed? In that case there > > > > > > > > Sure, if a doesn t exist. > > > > > > > >> probably needs to be some clarification of what it means for a > > > >> np-container to "exist" for the purpose of "must" evaluation. Our > > > >> implementation certainly considers a to "exist" if p exists > (regardless > > > >> of whether either of b and c exists) - and any other interpretation > > > >> seems bizarre to me, but maybe it isn't 110% clear from 6020& > > > > > > > > Bizarre? Sec. 7.5.8: > > > > > > > > If a container does not have a "presence" statement and the last > > > > child node is deleted, the NETCONF server MAY delete the > container. > > > > > > The point is - and this *is* expressed in 6020 (7.5.1) - that the > > > "existence" of a np-container has no semantics. What you are saying > (and > > > 6020 doesn't really contradict you) is that > > > > > > container p { > > > presence "foo"; > > > container a { > > > leaf b { > > > type ...; > > > mandatory true; > > > } > > > } > > > } > > > > > > and > > > > > > container p { > > > presence "foo"; > > > container a { > > > must "b"; > > > leaf b { > > > type ...; > > > } > > > } > > > } > > > > > > mean radically different things, and actually that the semantics of the > > > latter is basically undefined, since it would depend on whether > > > container a "happened to" exist, even though it can neither be created > > > nor deleted explicitly, and its existence isn't supposed to have any > > > semantics. > > > > > > I'm "pretty" sure this is not the intention of the authors. I seems > what > > > is needed is a clarification (in 7.5.3) of when the "must" statements > of > > > a np-container apply, similar to what is done for "mandatory" in 7.6.5. > > Yes, I agree with this. > > Since the NP-container itself has no semantics, so it cannot change > the meaning of must or mandatory leafs. > > Thus, the requested functionality can be done today with "must". > > > > I am confused. > > These examples are different. > > In the first container 'p' definition, container 'a' is mandatory because > > NP-containers with mandatory child nodes are mandatory. > > In the 2nd definition, leaf 'b' must be present if its parent container > 'a' > > is present, but the 'a' container is not itself mandatory. > > > > There is a hack (and also a demonstration of why this request may be > > reasonable after all): > > > > choice mandatory-np-container { > > mandatory true; > > container np-container { ... } > > } > > > > I just made a mandatory NP-container. > > Is this workaround good enough or should 'mandatory true' be allowed > > directly in the NP container? > > Having a "mandatory NP container" in itself makes no sense. Since the > NP container doesn't have any semantics, what does it mean to make it > mandatory? > > I don't think we should allow "mandatory" in an NP container just b/c > this hack exists. > > If a NP-container has a mandatory subnode, it means this NP-container is a actually mandatory node , although it has no 'mandatory' sub stmt. The problem that i want to solve is the union of two or more sub nodes are mandatory,so, the NP-container is actually mandatory. but there is no method to express this situation. The way to define 'must' expression under np-container can not make it be mandatory. > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11343920e32d7304f7a3457d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



    2014-04-22 14:46 GMT+08:00 Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com>:
    Andy= Bierman <andy@yumaworks.com&g= t; wrote:
    > On Mon, Apr 21, 2014 at 2:08 PM, Per Hedeland <per@tail-f.com> wrote:
    >
    > > On 2014-04-21 22:36, Ladislav Lhotka wrote:
    > > >
    > > > On 21 Apr 2014, at 22:11, Per Hedeland <per@tail-f.com> wrote:
    > > >
    > > >> On 2014-04-21 21:52, Per Hedeland wrote:
    > > >>> On 2014-04-21 19:57, Ladislav Lhotka wrote:
    > > >>>>
    > > >>>> On 21 Apr 2014, at 15:13, Andy Bierman <andy@yumaworks.com> wrote:
    > > >>>>
    > > >>>>>
    > > >>>>>
    > > >>>>>
    > > >>>>> On Mon, Apr 21, 2014 at 5:25 AM, chong feng = <fengchongllly@gmail.com&= gt;
    > > wrote:
    > > >>>>> Hi all,
    > > >>>>> =C2=A0 =C2=A0I suggest add 'mandatory= 9; to container to solve the problem
    > > listed below:
    > > >>>>> =C2=A0 =C2=A0container a {
    > > >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf b; > > >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf c; > > >>>>> =C2=A0 =C2=A0}
    > > >>>>>
    > > >>>>> =C2=A0 =C2=A0user can set b or set c or set = b and c,but at least one is
    > > assigned.
    > > >>>>>
    > > >>>>>
    > > >>>>>
    > > >>>>> You can use must-stmt:
    > > >>>>>
    > > >>>>> =C2=A0 container a {
    > > >>>>> =C2=A0 =C2=A0 =C2=A0must "b or c";=
    > > >>>>> =C2=A0 =C2=A0 =C2=A0leaf b { ...}
    > > >>>>> =C2=A0 =C2=A0 =C2=A0leaf c {...}
    > > >>>>> =C2=A0 }
    > > >>>>
    > > >>>> This doesn t work. If container =C2=A0a" do= esn t exist in the data tree,
    > > the must constraint doesn t apply (second paragraph in sec. 7.5.3= ).
    > > >>>
    > > >>> You seem to be assuming that the suggested "man= datory" on a container
    > > >>> should be radically different from the existing &quo= t;mandatory" on leafs
    > > and
    > > >>> choices - why? If container a doesn't exist, &qu= ot;mandatory" on e.g. leaf b
    > > >>> has no effect - nor should the suggested "manda= tory" on container a,
    > > >>> meaning "b and/or c must be set", have any= effect. Consider
    > > >>>
    > > >>> =C2=A0 container p {
    > > >>> =C2=A0 =C2=A0 presence "foo";
    > > >>> =C2=A0 =C2=A0 container a {
    > > >>> =C2=A0 =C2=A0 =C2=A0 mandatory true; =C2=A0// new su= ggestion
    > > >>> =C2=A0 =C2=A0 =C2=A0 leaf b {...}
    > > >>> =C2=A0 =C2=A0 =C2=A0 leaf c {...}
    > > >>> =C2=A0 =C2=A0 }
    > > >>> =C2=A0 }
    > > >>>
    > > >>> If p doesn't exist, it would be completely unrea= sonable for the
    > > >>> "mandatory" on a to force p into existence= - and without that,
    > > obviously
    > > >>> neither b nor c could be set. At least it would be c= ompletely at odds
    > > >>> with the semantics of the existing "mandatory&q= uot; statement.
    > > >>>
    > > >>> Bottom line, "must" works just as well/bad= as the new suggestion.
    > > >>
    > > >> Hm, or are you saying that, with
    > > >>
    > > >> =C2=A0 container p {
    > > >> =C2=A0 =C2=A0 presence "foo";
    > > >> =C2=A0 =C2=A0 container a {
    > > >> =C2=A0 =C2=A0 =C2=A0 must "b or c";
    > > >> =C2=A0 =C2=A0 =C2=A0 leaf b {...}
    > > >> =C2=A0 =C2=A0 =C2=A0 leaf c {...}
    > > >> =C2=A0 =C2=A0 }
    > > >> =C2=A0 }
    > > >>
    > > >> - the "must" wouldn't apply even if p exis= ted? In that case there
    > > >
    > > > Sure, if =C2=A0a =C2=A0doesn t exist.
    > > >
    > > >> probably needs to be some clarification of what it means= for a
    > > >> np-container to "exist" for the purpose of &qu= ot;must" evaluation. Our
    > > >> implementation certainly considers a to "exist"= ; if p exists (regardless
    > > >> of whether either of b and c exists) - and any other int= erpretation
    > > >> seems bizarre to me, but maybe it isn't 110% clear f= rom 6020&
    > > >
    > > > Bizarre? Sec. 7.5.8:
    > > >
    > > > =C2=A0 =C2=A0If a container does not have a "presence&q= uot; statement and the last
    > > > =C2=A0 =C2=A0child node is deleted, the NETCONF server MAY d= elete the container.
    > >
    > > The point is - and this *is* expressed in 6020 (7.5.1) - that the=
    > > "existence" of a np-container has no semantics. What yo= u are saying (and
    > > 6020 doesn't really contradict you) is that
    > >
    > > =C2=A0 container p {
    > > =C2=A0 =C2=A0 presence "foo";
    > > =C2=A0 =C2=A0 container a {
    > > =C2=A0 =C2=A0 =C2=A0 leaf b {
    > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 type ...;
    > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
    > > =C2=A0 =C2=A0 =C2=A0 }
    > > =C2=A0 =C2=A0 }
    > > =C2=A0 }
    > >
    > > and
    > >
    > > =C2=A0 container p {
    > > =C2=A0 =C2=A0 presence "foo";
    > > =C2=A0 =C2=A0 container a {
    > > =C2=A0 =C2=A0 =C2=A0 must "b";
    > > =C2=A0 =C2=A0 =C2=A0 leaf b {
    > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 type ...;
    > > =C2=A0 =C2=A0 =C2=A0 }
    > > =C2=A0 =C2=A0 }
    > > =C2=A0 }
    > >
    > > mean radically different things, and actually that the semantics = of the
    > > latter is basically undefined, since it would depend on whether > > container a "happened to" exist, even though it can nei= ther be created
    > > nor deleted explicitly, and its existence isn't supposed to h= ave any
    > > semantics.
    > >
    > > I'm "pretty" sure this is not the intention of the = authors. I seems what
    > > is needed is a clarification (in 7.5.3) of when the "must&qu= ot; statements of
    > > a np-container apply, similar to what is done for "mandatory= " in 7.6.5.

    Yes, I agree with this.

    Since the NP-container itself has no semantics, so it cannot change
    the meaning of must or mandatory leafs.

    Thus, the requested functionality can be done today with "must".<= br>


    > I am confused.
    > These examples are different.
    > In the first container 'p' definition, container 'a' i= s mandatory because
    > NP-containers with mandatory child nodes are mandatory.
    > In the 2nd definition, leaf 'b' must be present if its parent = container 'a'
    > is present, but the 'a' container is not itself mandatory.
    >
    > There is a hack (and also a demonstration of why this request may be > reasonable after all):
    >
    > =C2=A0 =C2=A0choice mandatory-np-container {
    > =C2=A0 =C2=A0 =C2=A0 mandatory true;
    > =C2=A0 =C2=A0 =C2=A0 container np-container { ... }
    > =C2=A0 =C2=A0 }
    >
    > I just made a mandatory NP-container.
    > Is this workaround good enough or should 'mandatory true' be a= llowed
    > directly in the NP container?

    Having a "mandatory NP container" in itself makes no sense.= =C2=A0Since the
    NP container doesn't have any semantics, what does it mean to make it mandatory?

    I don't think we should allow "mandatory" in an NP container = just b/c
    this hack exists.

    If a NP-container has a mandatory subnode, it means this NP-contain= er is a actually mandatory node ,
    =C2=A0although =C2=A0it has no = 'mandatory' sub stmt.=C2=A0

    The problem that i want to solve is the union of two or= more sub nodes are mandatory,so,=C2=A0
    the NP-container is actua= lly mandatory. but there is no method to express this situation.
    =
    The way to define 'must' expression under np-container = =C2=A0can not make it be mandatory.

    /martin

    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    = https://www.ietf.org/mailman/listinfo/netmod

    --001a11343920e32d7304f7a3457d-- From nobody Tue Apr 22 09:08:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F541A06A0 for ; Tue, 22 Apr 2014 09:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1nt16EQ_yMi for ; Tue, 22 Apr 2014 09:08:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E18ED1A069D for ; Tue, 22 Apr 2014 09:08:38 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A33F3B41CC; Tue, 22 Apr 2014 18:08:32 +0200 (CEST) Date: Tue, 22 Apr 2014 18:08:31 +0200 (CEST) Message-Id: <20140422.180831.493296198.mbj@tail-f.com> To: fengchongllly@gmail.com From: Martin Bjorklund In-Reply-To: References: <20140422.084622.570055904764562321.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gIWbFu5yp2jJlW-XpaoEtffyQQg Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 16:08:40 -0000 chong feng wrote: > The problem that i want to solve is the union of two or more sub nodes are > mandatory, Then it feels wrong to mark the container as mandatory. The must expression is imo more clear and direct. > so, the NP-container is actually mandatory. I disagree. One of the sub nodes must exist, and thus the NP container is needed. But the container itself is not mandatory. /martin From nobody Tue Apr 22 09:33:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE661A0222 for ; Tue, 22 Apr 2014 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XImv_gKFoDSX for ; Tue, 22 Apr 2014 09:32:57 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 608DB1A021F for ; Tue, 22 Apr 2014 09:32:57 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so5641314qcx.18 for ; Tue, 22 Apr 2014 09:32:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xcBCVb8jjTXISec7RdUgLnQHKtfJDoy/sjx3T+TIrbU=; b=hVl2p6meIdVamkYpGDnbhITquv8j9BAgVbhZbLcoTXS3zFUeiPKUZMVCPn9PRKAuks R4UZa0eE+VsaBzBEBKQLoGF4RyJK/n0zZ3CDSNRMgs16zPNCw+98i4hhontWm3b05WT/ vWpiXz7pUpCC+/M4Tx5TceeBrIazaN2k5IJ+M4G1SL4bbb1uPU+33ABs6PfATI2aSyok 1qmdhVTihF0cCJ4SIrBcQpvlFDxg8NuEwhv2Hj93oTfSnvBfVS94Jr27cjR0NKMfk6VN MlWhqJ/n4JnfJy2QQW6V6kgrrtMx4Rgi27ACMl/Ab7Ta/Ltb4euOvMrD0x4rDnK1Eoeq sTMA== X-Gm-Message-State: ALoCoQmOLpWhGTlMxUOYmBCTnC4u5IVk2DcfeixIk3VaJTRQTpFYzF5lcWhi9k7j/TxeGpMONKXa MIME-Version: 1.0 X-Received: by 10.224.136.74 with SMTP id q10mr44168326qat.78.1398184371588; Tue, 22 Apr 2014 09:32:51 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 22 Apr 2014 09:32:51 -0700 (PDT) In-Reply-To: <20140422.180831.493296198.mbj@tail-f.com> References: <20140422.084622.570055904764562321.mbj@tail-f.com> <20140422.180831.493296198.mbj@tail-f.com> Date: Tue, 22 Apr 2014 09:32:51 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2b61eccac2104f7a42a64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2St61NhJ2AX_nszVdVwHY1tVFUc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 16:33:01 -0000 --001a11c2b61eccac2104f7a42a64 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 22, 2014 at 9:08 AM, Martin Bjorklund wrote: > chong feng wrote: > > The problem that i want to solve is the union of two or more sub nodes > are > > mandatory, > > Then it feels wrong to mark the container as mandatory. The must > expression is imo more clear and direct. > > > so, the NP-container is actually mandatory. > > I disagree. One of the sub nodes must exist, and thus the NP > container is needed. But the container itself is not mandatory. > > Agreed. NP containers are not intuitive and it takes a little time to understand the transparency issues. There is no need to insist that all NP containers always exist, although that might make them easier to understand. I think you are objecting to this construct: container nonsense { mandatory true; } This would be legal but has no semantics. Actually, an NP container has some semantics. It represents a collection. This is real wrt/ naming isolation, must/when expressions, access control, and data retrieval filtering. So the statement above could be interpreted as a mandatory collection. It makes perfect sense for a config=false NP container. It seems to make sense for config=true as well. > /martin > Andy --001a11c2b61eccac2104f7a42a64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 22, 2014 at 9:08 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    chong feng <fengchongllly@gmail.com> wrote:
    > The problem that i want to solve is the union of two or more sub nodes= are
    > mandatory,

    Then it feels wrong to mark the container as mandatory. =A0The must
    expression is imo more clear and direct.

    > so, the NP-container is actually mandatory.

    I disagree. =A0One of the sub nodes must exist, and thus the NP
    container is needed. =A0But the container itself is not mandatory.


    Agreed.
    NP containers are not intuitive an= d it takes a little time to understand the
    transparency issues. = =A0There is no need to insist that all NP containers
    always exist, although that might make them easier to understand.

    I think you are objecting to this construct:

    =A0 =A0container nonsense {
    =A0 =A0 =A0 mandatory= true;
    =A0 =A0}

    This would be legal but has no seman= tics.

    Actually, an NP container has some semantics= .
    It represents a collection. =A0This is real wrt/ naming isolati= on,
    must/when expressions, access control, and data retrieval filtering.

    So the statement above could be interpreted as a ma= ndatory collection.
    It makes perfect sense for a config=3Dfalse N= P container. It seems to make
    sense for config=3Dtrue as well.



    /martin

    Andy<= /div>

    --001a11c2b61eccac2104f7a42a64-- From nobody Tue Apr 22 23:11:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927D71A0328 for ; Tue, 22 Apr 2014 23:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFl9Db8Aj9oe for ; Tue, 22 Apr 2014 23:10:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACDE1A0322 for ; Tue, 22 Apr 2014 23:10:52 -0700 (PDT) Received: from pluto.hedeland.org (h118n4-hy-d5.ias.bredband.telia.com [81.224.106.118]) by mail.tail-f.com (Postfix) with ESMTPSA id 86F9F3941F5; Wed, 23 Apr 2014 08:10:45 +0200 (CEST) Message-ID: <53575965.1040703@tail-f.com> Date: Wed, 23 Apr 2014 08:10:45 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ladislav Lhotka References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/D3aFlRFygFBp7kYhpQocpELCLKM Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:11:07 -0000 On 2014-04-22 14:29, Ladislav Lhotka wrote: > Per Hedeland writes: >> >> The point is - and this *is* expressed in 6020 (7.5.1) - that the >> "existence" of a np-container has no semantics. What you are saying (and > > They may not have semantics from YANG's viewpoint but they are still nodes in the data tree that either exist or not, and as such influence the context for XPath evaluation. > >> 6020 doesn't really contradict you) is that >> >> container p { >> presence "foo"; >> container a { >> leaf b { >> type ...; >> mandatory true; >> } >> } >> } >> >> and >> >> container p { >> presence "foo"; >> container a { >> must "b"; >> leaf b { >> type ...; >> } >> } >> } >> >> mean radically different things, and actually that the semantics of the > > They do mean different things! The "mandatory" statement is a schema constraint, and sec. 3.1 then explicitly states that "a" is a mandatory node. In contrast, "must" is a semantic constraint that (as any XPath expression) has to be evaluated in the well-defined context of a concrete XML instance document. And it is then significant whether the expression's context node exists or not. Well, in order to not get bogged down by theoretical discussions that I'm probably not smart enough to understand the relevance of, let me rephrase as "... radically different things regarding the enforcement of constraints on valid configuration data, as described in section 8 of RFC 6020 - in particular regarding any requirement that leaf "b" must exist in a valid configuration data tree". This aspect of the meaning of the first construct above is exactly specified by section 7.6.5 of 6020 (incidentally, without using either of the concepts "schema constraint" or "mandatory node"). It has no dependency on whether container "a" exists in the data tree or not, but it has a dependency on whether container "p" exists in the data tree or not. I assume we have no disagreement here. The same aspect of the meaning of the second construct is supposedly specified by section 7.5.3, which indeed does say If a data node does not exist in the data tree, and it does not have a default value, its "must" statements are not evaluated. I.e. it would appear to support "your view". However this interpretation actually results in "this aspect of the meaning" being undefined by 6020, since it depends on how/when a particular server implementation creates or deletes np-containers. Thus an that creates "p" but doesn't set a value for "b" may succeed with one server implementation (because it didn't create "a") but fail with another (because it did create "a"). This is obviously not interoperable. > It has been a recurring issue in the previous discussions about "must" and especially "when" that the meaning of XPath expressions is being sort of shifted to the schema, under the assumption that an implementation can (temporarily) insert dummy nodes here and there in the instance document, and that the gentle implementor will figure out the intentions of the data modeller. I think this is a wrong approach that can lead to interoperability problems and race conditions. > >> latter is basically undefined, since it would depend on whether >> container a "happened to" exist, even though it can neither be created >> nor deleted explicitly, and its existence isn't supposed to have any >> semantics. >> >> I'm "pretty" sure this is not the intention of the authors. I seems what >> is needed is a clarification (in 7.5.3) of when the "must" statements of >> a np-container apply, similar to what is done for "mandatory" in 7.6.5. > > To support your view, what's essentially needed is to state that NP-containers are always part of the default contents. I doubt that this is precisely what is needed - at the very least, the "closest ancestor node in the schema tree that is not a non-presence container" must come into play, as it does in 7.6.5, 7.7.3, and 7.9.4. But *something* is definitely needed - and I would suggest that this issue is separate from the one that started this discussion, the possibility of having 'mandatory' as substatement to 'container' - and that this should be reflected in the "issue list". --Per From nobody Wed Apr 23 00:40:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33271A00CF for ; Wed, 23 Apr 2014 00:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 530QXDOIZ4WX for ; Wed, 23 Apr 2014 00:40:10 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 931CA1A00C3 for ; Wed, 23 Apr 2014 00:40:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 36E6854075C; Wed, 23 Apr 2014 09:40:03 +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 P+NTR9eimLGg; Wed, 23 Apr 2014 09:39:57 +0200 (CEST) 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 9E24454000E; Wed, 23 Apr 2014 09:39:57 +0200 (CEST) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <53575965.1040703@tail-f.com> References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> <53575965.1040703@tail-f.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 23 Apr 2014 09:39:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6PimeEp4DrOrDgmDIRZPCAavMXg Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 07:40:15 -0000 Per Hedeland writes: > On 2014-04-22 14:29, Ladislav Lhotka wrote: >> Per Hedeland writes: >>> >>> The point is - and this *is* expressed in 6020 (7.5.1) - that the >>> "existence" of a np-container has no semantics. What you are saying (and >> >> They may not have semantics from YANG's viewpoint but they are still nodes in the data tree that either exist or not, and as such influence the context for XPath evaluation. >> >>> 6020 doesn't really contradict you) is that >>> >>> container p { >>> presence "foo"; >>> container a { >>> leaf b { >>> type ...; >>> mandatory true; >>> } >>> } >>> } >>> >>> and >>> >>> container p { >>> presence "foo"; >>> container a { >>> must "b"; >>> leaf b { >>> type ...; >>> } >>> } >>> } >>> >>> mean radically different things, and actually that the semantics of the >> >> They do mean different things! The "mandatory" statement is a schema constraint, and sec. 3.1 then explicitly states that "a" is a mandatory node. In contrast, "must" is a semantic constraint that (as any XPath expression) has to be evaluated in the well-defined context of a concrete XML instance document. And it is then significant whether the expression's context node exists or not. > > Well, in order to not get bogged down by theoretical discussions that This is no theoretical discussion, this is how off-the-shelf XPath processors work. If you generate DSDL schemas for the second version, Schematron validation will do exactly that: If the validated document contains only

    , no error will be reported, while for

    a validation error will be reported. In contrast, the "mandatory" statement is mapped straight to RELAX NG, so for the first variant an error will be reported in both cases. > I'm probably not smart enough to understand the relevance of, let me > rephrase as "... radically different things regarding the enforcement of > constraints on valid configuration data, as described in section 8 of > RFC 6020 - in particular regarding any requirement that leaf "b" must > exist in a valid configuration data tree". > > This aspect of the meaning of the first construct above is exactly > specified by section 7.6.5 of 6020 (incidentally, without using either > of the concepts "schema constraint" or "mandatory node"). It has no > dependency on whether container "a" exists in the data tree or not, but > it has a dependency on whether container "p" exists in the data tree or > not. I assume we have no disagreement here. Right. > > The same aspect of the meaning of the second construct is supposedly > specified by section 7.5.3, which indeed does say > > If a data node does not exist in the data tree, and it does not have > a default value, its "must" statements are not evaluated. > > I.e. it would appear to support "your view". However this interpretation > actually results in "this aspect of the meaning" being undefined by > 6020, since it depends on how/when a particular server implementation > creates or deletes np-containers. Thus an that creates "p" > but doesn't set a value for "b" may succeed with one server > implementation (because it didn't create "a") but fail with another > (because it did create "a"). This is obviously not interoperable. I agree this is not nice and needs to be addressed. > >> It has been a recurring issue in the previous discussions about "must" and especially "when" that the meaning of XPath expressions is being sort of shifted to the schema, under the assumption that an implementation can (temporarily) insert dummy nodes here and there in the instance document, and that the gentle implementor will figure out the intentions of the data modeller. I think this is a wrong approach that can lead to interoperability problems and race conditions. >> >>> latter is basically undefined, since it would depend on whether >>> container a "happened to" exist, even though it can neither be created >>> nor deleted explicitly, and its existence isn't supposed to have any >>> semantics. >>> >>> I'm "pretty" sure this is not the intention of the authors. I seems what >>> is needed is a clarification (in 7.5.3) of when the "must" statements of >>> a np-container apply, similar to what is done for "mandatory" in 7.6.5. >> >> To support your view, what's essentially needed is to state that NP-containers are always part of the default contents. > > I doubt that this is precisely what is needed - at the very least, the > "closest ancestor node in the schema tree that is not a non-presence > container" must come into play, as it does in 7.6.5, 7.7.3, and 7.9.4. Yes, exactly as it does for "normal" defaults. I think YANG 1.1 spec should also clearly distiguish between the use of the default contents 1. for validation purposes where the XML infoset has to be augmented with default contents, and 2. in NETCONF/RESTCONF messages where the default contents may be omitted (depending on with-defaults setting). I think the sentence in sec. 7.5.8 about deleting empty NP containers was intended for #2. > > But *something* is definitely needed - and I would suggest that this > issue is separate from the one that started this discussion, the > possibility of having 'mandatory' as substatement to 'container' - and > that this should be reflected in the "issue list". Agreed. Lada > > --Per -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 23 07:01:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96121A03A9 for ; Wed, 23 Apr 2014 07:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc0M9ZNfbR4T for ; Wed, 23 Apr 2014 07:01:26 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by ietfa.amsl.com (Postfix) with ESMTP id 49B881A020F for ; Wed, 23 Apr 2014 07:01:26 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id 63so964011qgz.9 for ; Wed, 23 Apr 2014 07:01:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WiwkebexW73hnrmHhV+Te2ijgX/YyIRmWJBgagNDaeM=; b=ULpZd6SIZoIUkJNnxiLYAbsyCsyqAdgaSsEOhASzz1ETBrR17C2OgpFAORyIB49+gh Ig/huhYI1+ZhO1X01uT0XJ0Z7GrY8/VNSND3EHFUrdus1c8i7EVTjRChbA8trOsCNcU1 PlnIklyrASWE4xwWAIT0AjYXqPpLUO/MDkEyvuMSGOiHFuSgfn78C5RuckndBAwPW4B3 dPYUlhLUL7vgQuOQpnTN2JUZwRk13L522GCLYp6KNTu4DyZy8Xv5SekTpB6hSHUv0lhs KYlkwSYbWTU3I4+y9EFLB+p1BoYm5migFB53GsrJh6GqufTrITTTw04ghmd3cpjfIA3G hSYQ== X-Gm-Message-State: ALoCoQmCOXYX6pga15+VFU+xqzxhJgIaz+KfrGh0AFcBdsTXXWrmm7OzKhwjD8tXxzSLMXwHg5yE MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr41881818qge.34.1398261680342; Wed, 23 Apr 2014 07:01:20 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 07:01:20 -0700 (PDT) In-Reply-To: References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> <53575965.1040703@tail-f.com> Date: Wed, 23 Apr 2014 07:01:20 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113abfd8c2ac4c04f7b62aa9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cWdWwF_8w1cCcDJ4FahZDm5EP0g Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:01:29 -0000 --001a113abfd8c2ac4c04f7b62aa9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 12:39 AM, Ladislav Lhotka wrote: > Per Hedeland writes: > > > On 2014-04-22 14:29, Ladislav Lhotka wrote: > >> Per Hedeland writes: > >>> > >>> The point is - and this *is* expressed in 6020 (7.5.1) - that the > >>> "existence" of a np-container has no semantics. What you are saying > (and > >> > >> They may not have semantics from YANG's viewpoint but they are still > nodes in the data tree that either exist or not, and as such influence the > context for XPath evaluation. > >> > >>> 6020 doesn't really contradict you) is that > >>> > >>> container p { > >>> presence "foo"; > >>> container a { > >>> leaf b { > >>> type ...; > >>> mandatory true; > >>> } > >>> } > >>> } > >>> > >>> and > >>> > >>> container p { > >>> presence "foo"; > >>> container a { > >>> must "b"; > >>> leaf b { > >>> type ...; > >>> } > >>> } > >>> } > >>> > >>> mean radically different things, and actually that the semantics of the > >> > >> They do mean different things! The "mandatory" statement is a schema > constraint, and sec. 3.1 then explicitly states that "a" is a mandatory > node. In contrast, "must" is a semantic constraint that (as any XPath > expression) has to be evaluated in the well-defined context of a concrete > XML instance document. And it is then significant whether the expression's > context node exists or not. > > > > Well, in order to not get bogged down by theoretical discussions that > > This is no theoretical discussion, this is how off-the-shelf XPath > processors work. If you generate DSDL schemas for the second version, > Schematron validation will do exactly that: If the validated document > contains only

    , no error will be reported, while for > >

    > >

    > > a validation error will be reported. > > In contrast, the "mandatory" statement is mapped straight to RELAX NG, so > for the first variant an error will be reported in both cases. > > > I'm probably not smart enough to understand the relevance of, let me > > rephrase as "... radically different things regarding the enforcement of > > constraints on valid configuration data, as described in section 8 of > > RFC 6020 - in particular regarding any requirement that leaf "b" must > > exist in a valid configuration data tree". > > > > This aspect of the meaning of the first construct above is exactly > > specified by section 7.6.5 of 6020 (incidentally, without using either > > of the concepts "schema constraint" or "mandatory node"). It has no > > dependency on whether container "a" exists in the data tree or not, but > > it has a dependency on whether container "p" exists in the data tree or > > not. I assume we have no disagreement here. > > Right. > > > > > The same aspect of the meaning of the second construct is supposedly > > specified by section 7.5.3, which indeed does say > > > > If a data node does not exist in the data tree, and it does not have > > a default value, its "must" statements are not evaluated. > > > > I.e. it would appear to support "your view". However this interpretation > > actually results in "this aspect of the meaning" being undefined by > > 6020, since it depends on how/when a particular server implementation > > creates or deletes np-containers. Thus an that creates "p" > > but doesn't set a value for "b" may succeed with one server > > implementation (because it didn't create "a") but fail with another > > (because it did create "a"). This is obviously not interoperable. > > I agree this is not nice and needs to be addressed. > > I do not understand the concerns here. If you have a must or when expression that tests the existence of a meaningless container, then that is just garbage-in/garbage-out. Don't write XPath that depends on NP containers. Make sure the tests are for meaningful nodes. > > > >> It has been a recurring issue in the previous discussions about "must" > and especially "when" that the meaning of XPath expressions is being sort > of shifted to the schema, under the assumption that an implementation can > (temporarily) insert dummy nodes here and there in the instance document, > and that the gentle implementor will figure out the intentions of the data > modeller. I think this is a wrong approach that can lead to > interoperability problems and race conditions. > >> > >>> latter is basically undefined, since it would depend on whether > >>> container a "happened to" exist, even though it can neither be created > >>> nor deleted explicitly, and its existence isn't supposed to have any > >>> semantics. > >>> > >>> I'm "pretty" sure this is not the intention of the authors. I seems > what > >>> is needed is a clarification (in 7.5.3) of when the "must" statements > of > >>> a np-container apply, similar to what is done for "mandatory" in 7.6.5. > >> > >> To support your view, what's essentially needed is to state that > NP-containers are always part of the default contents. > > > Why? So XPath expressions that test for the existence of meaningless containers will "work correctly"? > > I doubt that this is precisely what is needed - at the very least, the > > "closest ancestor node in the schema tree that is not a non-presence > > container" must come into play, as it does in 7.6.5, 7.7.3, and 7.9.4. > > Yes, exactly as it does for "normal" defaults. > > I think YANG 1.1 spec should also clearly distiguish between the use of > the default contents > > 1. for validation purposes where the XML infoset has to be augmented with > default contents, and > > 2. in NETCONF/RESTCONF messages where the default contents may be omitted > (depending on with-defaults setting). > > I think the sentence in sec. 7.5.8 about deleting empty NP containers was > intended for #2. > > > > > But *something* is definitely needed - and I would suggest that this > > issue is separate from the one that started this discussion, the > > possibility of having 'mandatory' as substatement to 'container' - and > > that this should be reflected in the "issue list". > > Agreed. > The current text says that servers MAY delete empty NP-containers since they are meaningless and just take up space in the config tree. Are you saying you want to change that so servers MUST create NP containers? > > Lada > > > > > --Per > > Andy --001a113abfd8c2ac4c04f7b62aa9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 23, 2014 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:
    Per Hedeland <per@tail-f.com> writes:

    > On 2014-04-22 14:29, Ladislav Lhotka wrote:
    >> Per Hedeland <per@tail-f.com<= /a>> writes:
    >>>
    >>> The point is - and this *is* expressed in 6020 (7.5.1) - that = the
    >>> "existence" of a np-container has no semantics. What= you are saying (and
    >>
    >> They may not have semantics from YANG's viewpoint but they are= still nodes in the data tree that either exist or not, and as such influen= ce the context for XPath evaluation.
    >>
    >>> 6020 doesn't really contradict you) is that
    >>>
    >>> =A0 container p {
    >>> =A0 =A0 presence "foo";
    >>> =A0 =A0 container a {
    >>> =A0 =A0 =A0 leaf b {
    >>> =A0 =A0 =A0 =A0 type ...;
    >>> =A0 =A0 =A0 =A0 mandatory true;
    >>> =A0 =A0 =A0 }
    >>> =A0 =A0 }
    >>> =A0 }
    >>>
    >>> and
    >>>
    >>> =A0 container p {
    >>> =A0 =A0 presence "foo";
    >>> =A0 =A0 container a {
    >>> =A0 =A0 =A0 must "b";
    >>> =A0 =A0 =A0 leaf b {
    >>> =A0 =A0 =A0 =A0 type ...;
    >>> =A0 =A0 =A0 }
    >>> =A0 =A0 }
    >>> =A0 }
    >>>
    >>> mean radically different things, and actually that the semanti= cs of the
    >>
    >> They do mean different things! The "mandatory" statement= is a schema constraint, and sec. 3.1 then explicitly states that "a&q= uot; is a mandatory node. In contrast, "must" is a semantic const= raint that (as any XPath expression) has to be evaluated in the well-define= d context of a concrete XML instance document. And it is then significant w= hether the expression's context node exists or not.
    >
    > Well, in order to not get bogged down by theoretical discussions that<= br>
    This is no theoretical discussion, this is how off-the-shelf XPath processo= rs work. If you generate DSDL schemas for the second version, Schematron va= lidation will do exactly that: If the validated document contains only <= p/>, no error will be reported, while for

    <p>
    =A0 <a/>
    </p>

    a validation error will be reported.

    In contrast, the "mandatory" statement is mapped straight to RELA= X NG, so for the first variant an error will be reported in both cases.

    > I'm probably not smart enough to understand the relevance of, let = me
    > rephrase as "... radically different things regarding the enforce= ment of
    > constraints on valid configuration data, as described in section 8 of<= br> > RFC 6020 - in particular regarding any requirement that leaf "b&q= uot; must
    > exist in a valid configuration data tree".
    >
    > This aspect of the meaning of the first construct above is exactly
    > specified by section 7.6.5 of 6020 (incidentally, without using either=
    > of the concepts "schema constraint" or "mandatory node&= quot;). It has no
    > dependency on whether container "a" exists in the data tree = or not, but
    > it has a dependency on whether container "p" exists in the d= ata tree or
    > not. I assume we have no disagreement here.

    Right.

    >
    > The same aspect of the meaning of the second construct is supposedly > specified by section 7.5.3, which indeed does say
    >
    > =A0 =A0 If a data node does not exist in the data tree, and it does no= t have
    > =A0 =A0 a default value, its "must" statements are not evalu= ated.
    >
    > I.e. it would appear to support "your view". However this in= terpretation
    > actually results in "this aspect of the meaning" being undef= ined by
    > 6020, since it depends on how/when a particular server implementation<= br> > creates or deletes np-containers. Thus an <edit-config> that cre= ates "p"
    > but doesn't set a value for "b" may succeed with one ser= ver
    > implementation (because it didn't create "a") but fail w= ith another
    > (because it did create "a"). This is obviously not interoper= able.

    I agree this is not nice and needs to be addressed.



    Don't write XPath that depends on NP containers. =A0Make sure the<= /div>
    tests are for meaningful nodes.

    =A0
    <= /div>
    >
    >> It has been a recurring issue in the previous discussions about &q= uot;must" and especially "when" that the meaning of XPath ex= pressions is being sort of shifted to the schema, under the assumption that= an implementation can (temporarily) insert dummy nodes here and there in t= he instance document, and that the gentle implementor will figure out the i= ntentions of the data modeller. I think this is a wrong approach that can l= ead to interoperability problems and race conditions.
    >>
    >>> latter is basically undefined, since it would depend on whethe= r
    >>> container a "happened to" exist, even though it can = neither be created
    >>> nor deleted explicitly, and its existence isn't supposed t= o have any
    >>> semantics.
    >>>
    >>> I'm "pretty" sure this is not the intention of t= he authors. I seems what
    >>> is needed is a clarification (in 7.5.3) of when the "must= " statements of
    >>> a np-container apply, similar to what is done for "mandat= ory" in 7.6.5.
    >>
    >> To support your view, what's essentially needed is to state th= at NP-containers are always part of the default contents.
    >


    Why?
    So X= Path expressions that test for the existence of meaningless containers
    will "work correctly"?

    =A0
    > I doubt that this is precisely what is needed - at the very least, the=
    > "closest ancestor node in the schema tree that is not a non-prese= nce
    > container" must come into play, as it does in 7.6.5, 7.7.3, and 7= .9.4.

    Yes, exactly as it does for "normal" defaults.

    I think YANG 1.1 spec should also clearly distiguish between the use of the= default contents

    1. for validation purposes where the XML infoset has to be augmented with d= efault contents, and

    2. in NETCONF/RESTCONF messages where the default contents may be omitted (= depending on with-defaults setting).

    I think the sentence in sec. 7.5.8 about deleting empty NP containers was i= ntended for #2.

    >
    > But *something* is definitely needed - and I would suggest that this > issue is separate from the one that started this discussion, the
    > possibility of having 'mandatory' as substatement to 'cont= ainer' - and
    > that this should be reflected in the "issue list".

    Agreed.

    The current text says that serv= ers MAY delete empty NP-containers
    since they are meaningless and= just take up space in the config tree.
    Are you saying you want t= o change that so servers MUST
    create NP containers?


    =A0

    Lada

    >
    > --Per


    Andy

    --001a113abfd8c2ac4c04f7b62aa9-- From nobody Wed Apr 23 07:18:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D3C1A021C for ; Wed, 23 Apr 2014 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy7CRkg3Ip7Z for ; Wed, 23 Apr 2014 07: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 B43421A020A for ; Wed, 23 Apr 2014 07:18:52 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6132813F7DA; Wed, 23 Apr 2014 16:18:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398262726; bh=pEuHC4b5XXsLxM3z+jYssHBEW6ZAMgKPxJ5aw2hnn4g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fFwT2AERos1MgKehvzGm+zkc7tUOMkdyXKG9ubk1l+eeZEnssY56TCEuiAWykPfZu qNpWHptvQL/WYBa7y3R+xXjrMdIquyOxBQ8XYMZvpN8zrlMXRG3nddYoHuXJCakCWN 1RVZ+YJJFuy8zetLG4CDQMwdjc3KmAgSj8ssozoY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 23 Apr 2014 16:18:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8EC4395B-39B6-451F-A834-A78BA153C468@nic.cz> <535576FA.8040401@tail-f.com> <53557B7A.5020306@tail-f.com> <883163DB-F3C4-4F24-9432-9B1E6D2B66A2@nic.cz> <535588B7.3080401@tail-f.com> <53575965.1040703@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/613uihDM6lSxrec_j0OiuZNLHCU Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG1.1 new issue: add 'mandatory' to container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:18:55 -0000 On 23 Apr 2014, at 16:01, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Apr 23, 2014 at 12:39 AM, Ladislav Lhotka = wrote: > Per Hedeland writes: >=20 > > On 2014-04-22 14:29, Ladislav Lhotka wrote: > >> Per Hedeland writes: > >>> > >>> The point is - and this *is* expressed in 6020 (7.5.1) - that the > >>> "existence" of a np-container has no semantics. What you are = saying (and > >> > >> They may not have semantics from YANG's viewpoint but they are = still nodes in the data tree that either exist or not, and as such = influence the context for XPath evaluation. > >> > >>> 6020 doesn't really contradict you) is that > >>> > >>> container p { > >>> presence "foo"; > >>> container a { > >>> leaf b { > >>> type ...; > >>> mandatory true; > >>> } > >>> } > >>> } > >>> > >>> and > >>> > >>> container p { > >>> presence "foo"; > >>> container a { > >>> must "b"; > >>> leaf b { > >>> type ...; > >>> } > >>> } > >>> } > >>> > >>> mean radically different things, and actually that the semantics = of the > >> > >> They do mean different things! The "mandatory" statement is a = schema constraint, and sec. 3.1 then explicitly states that "a" is a = mandatory node. In contrast, "must" is a semantic constraint that (as = any XPath expression) has to be evaluated in the well-defined context of = a concrete XML instance document. And it is then significant whether the = expression's context node exists or not. > > > > Well, in order to not get bogged down by theoretical discussions = that >=20 > This is no theoretical discussion, this is how off-the-shelf XPath = processors work. If you generate DSDL schemas for the second version, = Schematron validation will do exactly that: If the validated document = contains only

    , no error will be reported, while for >=20 >

    > >

    >=20 > a validation error will be reported. >=20 > In contrast, the "mandatory" statement is mapped straight to RELAX NG, = so for the first variant an error will be reported in both cases. >=20 > > I'm probably not smart enough to understand the relevance of, let me > > rephrase as "... radically different things regarding the = enforcement of > > constraints on valid configuration data, as described in section 8 = of > > RFC 6020 - in particular regarding any requirement that leaf "b" = must > > exist in a valid configuration data tree". > > > > This aspect of the meaning of the first construct above is exactly > > specified by section 7.6.5 of 6020 (incidentally, without using = either > > of the concepts "schema constraint" or "mandatory node"). It has no > > dependency on whether container "a" exists in the data tree or not, = but > > it has a dependency on whether container "p" exists in the data tree = or > > not. I assume we have no disagreement here. >=20 > Right. >=20 > > > > The same aspect of the meaning of the second construct is supposedly > > specified by section 7.5.3, which indeed does say > > > > If a data node does not exist in the data tree, and it does not = have > > a default value, its "mu