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 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 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, piše 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, piše 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 "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. >=20 > I agree this is not nice and needs to be addressed. >=20 >=20 >=20 > 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 is not about testing existence of containers. The problem is with = XPath expressions whose context nodes are NP containers: depending on = whether such a container exists in the instance data tree, the must = constraint may or may not be applied - see my example above. >=20 > =20 > > > >> 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. > > >=20 >=20 > Why? > So XPath expressions that test for the existence of meaningless = containers > will "work correctly=94? No - so that XPath expressions will be applied in a deterministic way. . >=20 > =20 > > 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. >=20 > Yes, exactly as it does for "normal" defaults. >=20 > I think YANG 1.1 spec should also clearly distiguish between the use = of the default contents >=20 > 1. for validation purposes where the XML infoset has to be augmented = with default contents, and >=20 > 2. in NETCONF/RESTCONF messages where the default contents may be = omitted (depending on with-defaults setting). >=20 > I think the sentence in sec. 7.5.8 about deleting empty NP containers = was intended for #2. >=20 > > > > 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". >=20 > Agreed. >=20 > 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? If the NP container has a must statement as its child, then - if the server deletes the container from the data tree, the must = constraint doesn=92t apply - otherwise, the container stays in the data tree and the must = constraint applies. This is hardly acceptable. Lada >=20 >=20 > =20 >=20 > Lada >=20 > > > > --Per >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 23 07:28: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 922871A03C5 for ; Wed, 23 Apr 2014 07:28:09 -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 bhjjJ1GP-LPc for ; Wed, 23 Apr 2014 07:28:06 -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 0423B1A03C1 for ; Wed, 23 Apr 2014 07:28:05 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so994354qge.2 for ; Wed, 23 Apr 2014 07:28:00 -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=m2CTQ2NtrmOuVFf4KHFfN8bU7LNixh29O5BDO8Vu2OM=; b=WJOYV9sPtHkeqmiTabc5XiNmq6CNinfhob3HVWKegg8SfafBefueWGzfeOye2cf1uP grHU3YUCGf4yQilm7nnDt7QwyZ48PX/kwWSazikji3q8eqOE5TByFCDrNLgtyABZ5rxF yaNiMELev0yY2ElUlJDukKlN/wiKDZIX/VzyYUogQIsbmt5JRvAqIyj2bZdGWWCprZIN usw+4MZGFTB1BIWHrWXq66HYevWe0xMhQNGY0YwLygRt5FdBZ1uD0kpu3oVDL8NL0mDP lHVrD3CAFZpycaNYQ2jQPynIrfN1UBUZ7MmBiHHMVnsnT9Yh7q29j8J/H0x/HQ8v6v5z ZHSQ== X-Gm-Message-State: ALoCoQlQQcb2ahRFeP83v7mLnP8LOWsihOXEzKuQYaWijtxwFtk8Uuhb0/g3WPJdADLz5awvkHF9 MIME-Version: 1.0 X-Received: by 10.140.27.212 with SMTP id 78mr60325611qgx.18.1398263280002; Wed, 23 Apr 2014 07:28:00 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 07:27:59 -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:27:59 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c14d661b9a3804f7b68a1a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IIwv9g2jmncEF_2UvMLVjmKJNCM 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:28:09 -0000 --001a11c14d661b9a3804f7b68a1a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 7:18 AM, Ladislav Lhotka wrote: > > On 23 Apr 2014, at 16:01, Andy Bierman wrote: > > > > > > > > > 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 is not about testing existence of containers. The problem is with XPath > expressions whose context nodes are NP containers: depending on whether > such a container exists in the instance data tree, the must constraint may > or may not be applied - see my example above. > > > > > > > > > > >> 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"? > > No - so that XPath expressions will be applied in a deterministic way. > . > > > > > > > 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? > > If the NP container has a must statement as its child, then > > - if the server deletes the container from the data tree, the must > constraint doesn't apply > > - otherwise, the container stays in the data tree and the must constraint > applies. > > This is hardly acceptable. > > Again -- garbage-in/garbage-out. YANG allows plenty of constructs, such as top-level mandatory nodes, which "in theory" are completely broken and unacceptable. So what. Don't put must-stmt in an empty NP container. This is an extremely minor corner-case. In general, the server does not want meaningless nodes cluttering up the database. > Lada > > Andy > > > > > > > > > > Lada > > > > > > > > --Per > > > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c14d661b9a3804f7b68a1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 23, 2014 at 7:18 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

    On 23 Apr 2014, at 16:01, Andy Bierman <andy@yumaworks.com> wrote:

    >
    >
    >
    > On Wed, Apr 23, 2014 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
    > Per Hedeland <per@tail-f.com&= gt; writes:
    >
    > > On 2014-04-22 14:29, Ladislav Lhotka wrote:
    > >> Per Hedeland <per@tail-f= .com> 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 the= y are still nodes in the data tree that either exist or not, and as such in= fluence 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 se= mantics of the
    > >>
    > >> They do mean different things! The "mandatory" stat= ement is a schema constraint, and sec. 3.1 then explicitly states that &quo= t;a" is a mandatory node. In contrast, "must" is a semantic = constraint that (as any XPath expression) has to be evaluated in the well-d= efined context of a concrete XML instance document. And it is then signific= ant 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 pro= cessors work. If you generate DSDL schemas for the second version, Schematr= on validation will do exactly that: If the validated document contains only= <p/>, no error will be reported, while for
    >
    > <p>
    >   <a/>
    > </p>
    >
    > 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 en= forcement of
    > > constraints on valid configuration data, as described in section = 8 of
    > > RFC 6020 - in particular regarding any requirement that leaf &quo= t;b" must
    > > exist in a valid configuration data tree".
    > >
    > > This aspect of the meaning of the first construct above is exactl= y
    > > specified by section 7.6.5 of 6020 (incidentally, without using e= ither
    > > 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 suppose= dly
    > > 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 ar= e not evaluated.
    > >
    > > I.e. it would appear to support "your view". However th= is interpretation
    > > actually results in "this aspect of the meaning" being = undefined by
    > > 6020, since it depends on how/when a particular server implementa= tion
    > > creates or deletes np-containers. Thus an <edit-config> tha= t creates "p"
    > > but doesn't set a value for "b" may succeed with on= e server
    > > implementation (because it didn't create "a") but f= ail with another
    > > (because it did create "a"). This is obviously not inte= roperable.
    >
    > 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 t= he
    > tests are for meaningful nodes.

    It is not about testing existence of containers. The problem is with XPath = expressions whose context nodes are NP containers: depending on whether suc= h a container exists in the instance data tree, the must constraint may or = may not be applied - see my example above.

    >
    >
    > >
    > >> It has been a recurring issue in the previous discussions abo= ut "must" and especially "when" that the meaning of XPa= th 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 w= hether
    > >>> container a "happened to" exist, even though it= can neither be created
    > >>> nor deleted explicitly, and its existence isn't suppo= sed 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 "m= andatory" in 7.6.5.
    > >>
    > >> To support your view, what's essentially needed is to sta= te that NP-containers are always part of the default contents.
    > >
    >
    >
    > Why?
    > So XPath expressions that test for the existence of meaningless contai= ners
    > will "work correctly”?

    No - so that XPath expressions will be applied in a deterministic way.
    .
    >
    >
    > > 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 o= f the default contents
    >
    > 1. for validation purposes where the XML infoset has to be augmented w= ith default contents, and
    >
    > 2. in NETCONF/RESTCONF messages where the default contents may be omit= ted (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 t= his
    > > issue is separate from the one that started this discussion, the<= br> > > 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.<= br> > Are you saying you want to change that so servers MUST
    > create NP containers?

    If the NP container has a must statement as its child, then

    - if the server deletes the container from the data tree, the must constrai= nt doesn’t apply

    - otherwise, the container stays in the data tree and the must constraint a= pplies.

    This is hardly acceptable.


    Again -- garbage-in/garbage-out.
    =
    YANG allows plenty of constructs, such as top-level mandatory nodes,
    which "in theory" are completely broken and unacceptable= . So what.

    Don't put must-stmt in an empty NP container.
    =
    This is an extremely minor corner-case.  In general, the server d= oes
    not want meaningless nodes cluttering up the database.
    <= div>
     
    Lada


    Andy
     
    >
    >
    >
    >
    > Lada
    >
    > >
    > > --Per
    >
    >
    > Andy
    >

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





    --001a11c14d661b9a3804f7b68a1a-- From nobody Wed Apr 23 07:34: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 9A3C91A03AE for ; Wed, 23 Apr 2014 07:34: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 3I_PjZgfc3TE for ; Wed, 23 Apr 2014 07:34:18 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E794F1A02B5 for ; Wed, 23 Apr 2014 07:34:17 -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 52F1137C360; Wed, 23 Apr 2014 16:34:11 +0200 (CEST) Date: Wed, 23 Apr 2014 16:34:10 +0200 (CEST) Message-Id: <20140423.163410.854569166179772174.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/AEsTROjdI_NjKCfa4hlFV2GEQcA 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:34:19 -0000 Andy Bierman wrote: > Don't put must-stmt in an empty NP container. This isn't the issue. Here's an example of the problem: container top { presence "..."; container foo { must "a or b"; leaf a { ... } leaf b { ... } } } When /top is created, we want a or b to exist. The behaviour is not clear from RFC 6020. We need to make this clear. (I'll add this as a separate clarification issue) /martin From nobody Wed Apr 23 07:36:27 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 B7C1B1A03C3 for ; Wed, 23 Apr 2014 07:36:24 -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 J0q1qzxPbnzT for ; Wed, 23 Apr 2014 07:36:21 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by ietfa.amsl.com (Postfix) with ESMTP id CB7831A03AE for ; Wed, 23 Apr 2014 07:36:20 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q107so328256qgd.41 for ; Wed, 23 Apr 2014 07:36: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=9Md3Q5X/ZhIc5j4RpGizwjMAiU8azwCrX7SvECopeuU=; b=PDcrEK1NLjezXpLiS43PgCQxE6EQjDenyLXe1aP2ZVGnGfAhAexUWNpJ22+IUIIiFU 4/eab+jtw56Pvu+1+9QjnwyYr91FeXSvfZL5XTf1JCJitMngGERL6Asp/31Ja1vD69Bi rb2A08SlLUWvCBsxMA5BA9qYKo81pFj5DKwyMLD9G6XfXz5JeNLj4JldfyWPi8n0fLfc cvbDK4L34nBzVF+ORMxojBmNWULEAzalPosFIGg3TxR+KGvN+bhI30BE1zlzDKWbxkc3 fKass63gbfFjfKKKGpamssq4GFppJ3Fa+CAZoNTQtm4FfAv7AAQIMsthvbmhCG9BCvEi mnWQ== X-Gm-Message-State: ALoCoQk9mHI6y3ztHGKt/bpi7i6qXP5XqE55pjc34xEeCjpPIVuIpCIyBgSaHn3Ztl895cqDpKgB MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr59049192qai.16.1398263774878; Wed, 23 Apr 2014 07:36:14 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 07:36:14 -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:36:14 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c20e7a9ad1f104f7b6a740 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bAlq0ET9a4fjvcNvgOTox4TbKLI 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:36:24 -0000 --001a11c20e7a9ad1f104f7b6a740 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 7:18 AM, Ladislav Lhotka wrote: > > On 23 Apr 2014, at 16:01, Andy Bierman wrote: > > > > > > > > > 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 is not about testing existence of containers. The problem is with XPath > expressions whose context nodes are NP containers: depending on whether > such a container exists in the instance data tree, the must constraint may > or may not be applied - see my example above. > > > > > > > > > > >> 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"? > > No - so that XPath expressions will be applied in a deterministic way. > . > > > > > > > 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. > I agree it is an open issue. I think some implementations actually have the server create NP containers, not just delete them. I am more concerned with consistent handling of the create and delete operations than XPath. If the server creates an NP-container on some implementations then a client create operation will fail, depending on the implementation. (Unlike with-defaults, there is no basic-mode defining what the server will do.) Andy > > > > 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? > > If the NP container has a must statement as its child, then > > - if the server deletes the container from the data tree, the must > constraint doesn't apply > > - otherwise, the container stays in the data tree and the must constraint > applies. > > This is hardly acceptable. > > Lada > > > > > > > > > > > Lada > > > > > > > > --Per > > > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c20e7a9ad1f104f7b6a740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 23, 2014 at 7:18 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

    On 23 Apr 2014, at 16:01, Andy Bierman <andy@yumaworks.com> wrote:

    >
    >
    >
    > On Wed, Apr 23, 2014 at 12:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
    > Per Hedeland <per@tail-f.com&= gt; writes:
    >
    > > On 2014-04-22 14:29, Ladislav Lhotka wrote:
    > >> Per Hedeland <per@tail-f= .com> 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 the= y are still nodes in the data tree that either exist or not, and as such in= fluence 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 se= mantics of the
    > >>
    > >> They do mean different things! The "mandatory" stat= ement is a schema constraint, and sec. 3.1 then explicitly states that &quo= t;a" is a mandatory node. In contrast, "must" is a semantic = constraint that (as any XPath expression) has to be evaluated in the well-d= efined context of a concrete XML instance document. And it is then signific= ant 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 pro= cessors work. If you generate DSDL schemas for the second version, Schematr= on validation will do exactly that: If the validated document contains only= <p/>, no error will be reported, while for
    >
    > <p>
    >   <a/>
    > </p>
    >
    > 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 en= forcement of
    > > constraints on valid configuration data, as described in section = 8 of
    > > RFC 6020 - in particular regarding any requirement that leaf &quo= t;b" must
    > > exist in a valid configuration data tree".
    > >
    > > This aspect of the meaning of the first construct above is exactl= y
    > > specified by section 7.6.5 of 6020 (incidentally, without using e= ither
    > > 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 suppose= dly
    > > 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 ar= e not evaluated.
    > >
    > > I.e. it would appear to support "your view". However th= is interpretation
    > > actually results in "this aspect of the meaning" being = undefined by
    > > 6020, since it depends on how/when a particular server implementa= tion
    > > creates or deletes np-containers. Thus an <edit-config> tha= t creates "p"
    > > but doesn't set a value for "b" may succeed with on= e server
    > > implementation (because it didn't create "a") but f= ail with another
    > > (because it did create "a"). This is obviously not inte= roperable.
    >
    > 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 t= he
    > tests are for meaningful nodes.

    It is not about testing existence of containers. The problem is with XPath = expressions whose context nodes are NP containers: depending on whether suc= h a container exists in the instance data tree, the must constraint may or = may not be applied - see my example above.

    >
    >
    > >
    > >> It has been a recurring issue in the previous discussions abo= ut "must" and especially "when" that the meaning of XPa= th 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 w= hether
    > >>> container a "happened to" exist, even though it= can neither be created
    > >>> nor deleted explicitly, and its existence isn't suppo= sed 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 "m= andatory" in 7.6.5.
    > >>
    > >> To support your view, what's essentially needed is to sta= te that NP-containers are always part of the default contents.
    > >
    >
    >
    > Why?
    > So XPath expressions that test for the existence of meaningless contai= ners
    > will "work correctly”?

    No - so that XPath expressions will be applied in a deterministic way.
    .
    >
    >
    > > 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 o= f the default contents
    >
    > 1. for validation purposes where the XML infoset has to be augmented w= ith default contents, and
    >
    > 2. in NETCONF/RESTCONF messages where the default contents may be omit= ted (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 t= his
    > > issue is separate from the one that started this discussion, the<= br> > > possibility of having 'mandatory' as substatement to '= ;container' - and
    > > that this should be reflected in the "issue list".
    >
    > Agreed.

    I agree it is an open issu= e.
    I think some implementations actually have the server create N= P containers,
    not just delete them.  I am more concerned wit= h consistent handling of
    the create and delete operations than XPath.  If the server creat= es an
    NP-container on some implementations then a client create o= peration will fail,
    depending on the implementation. (Unlike with= -defaults, there is no basic-mode
    defining what the server will do.)


    =
    Andy

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

    If the NP container has a must statement as its child, then

    - if the server deletes the container from the data tree, the must constrai= nt doesn’t apply

    - otherwise, the container stays in the data tree and the must constraint a= pplies.

    This is hardly acceptable.

    Lada

    >
    >
    >
    >
    > Lada
    >
    > >
    > > --Per
    >
    >
    > Andy
    >

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





    --001a11c20e7a9ad1f104f7b6a740-- From nobody Wed Apr 23 07:39: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 16BEF1A03D8 for ; Wed, 23 Apr 2014 07:39:34 -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 H6mdb0pWHQhG for ; Wed, 23 Apr 2014 07:39:32 -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 A92541A03D3 for ; Wed, 23 Apr 2014 07:39:31 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so1011338qcx.32 for ; Wed, 23 Apr 2014 07:39:25 -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=kb9EklVOlB3cF217+AjdAkCF76/x+jA8CDEnSUQ1aSU=; b=LWi1lkW5QuE5bIk7cofHIiGd0SGqMS81Hm+pmuToOP0Te9dlCEILpbGcphumZFu3Hm jSVl9O+nCHuIuR9urTUenNwCWgYo8kzHR4uK0F/rSXvqFj9zzjx2qiUBVT6y2ZETWeD5 D9X/bpG/JAv1xArfCxzmxJrPTcg+gXF/LR7xCT5nk7B8HmVqaPrzCcUntftlEA4f+Gyj U/tcZu4UjGr3uwF7O7R76AvJECKMvm5g7GFylJC+ipkdn8ySMyowdrj6W4LmJbzaEWHG yVyrF36Qmpfn8yq35kYPQj3gUgVa0UFrG6HpkcN51f/5S/K5RCFyHvz6SlwBGGloPUHQ 0IPQ== X-Gm-Message-State: ALoCoQlXGlKIXMC/9hDEvABBpm3A2sGG/QZmtQpQH0KixT2q051HmfIqOl+0JVEPmgDk7W3oDznG MIME-Version: 1.0 X-Received: by 10.224.136.74 with SMTP id q10mr52066354qat.78.1398263965802; Wed, 23 Apr 2014 07:39:25 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 07:39:25 -0700 (PDT) In-Reply-To: <20140423.163410.854569166179772174.mbj@tail-f.com> References: <20140423.163410.854569166179772174.mbj@tail-f.com> Date: Wed, 23 Apr 2014 07:39:25 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2b61efbfb8404f7b6b22a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ACXmKntxUuJtfn8S2rPo3sSYluQ 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:39:34 -0000 --001a11c2b61efbfb8404f7b6b22a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 7:34 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Don't put must-stmt in an empty NP container. > > This isn't the issue. Here's an example of the problem: > > container top { > presence "..."; > container foo { > must "a or b"; > leaf a { ... } > leaf b { ... } > } > } > > When /top is created, we want a or b to exist. > > So use the correct XPath: container top { presence "..."; must "foo/a or foo/b"; container foo { leaf a { ... } leaf b { ... } } } > The behaviour is not clear from RFC 6020. We need to make this clear. > > (I'll add this as a separate clarification issue) > > > /martin > Andy --001a11c2b61efbfb8404f7b6b22a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 23, 2014 at 7:34 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    Andy Bierman <and= y@yumaworks.com> wrote:
    > Don't put must-stmt in an empty NP container.

    This isn't the issue. =A0Here's an example of the problem:

    =A0 container top {
    =A0 =A0 presence "...";
    =A0 =A0 container foo {
    =A0 =A0 =A0 must "a or b";
    =A0 =A0 =A0 leaf a { ... }
    =A0 =A0 =A0 leaf b { ... }
    =A0 =A0 }
    =A0 }

    When /top is created, we want a or b to exist.


    So use the correct XPath:

    =A0container top {
    =A0 =A0 presence "= ...";
    =A0 =A0 must "foo/a or foo/= b";
    =A0 =A0 container foo {
    =A0 =A0 =A0 leaf a { ... }
    =A0 =A0 =A0 leaf b= { ... }
    =A0 =A0 }
    =A0 }


    =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"> The behaviour is not clear from RFC 6020. =A0We need to make this clear.
    (I'll add this as a separate clarification issue)


    /martin


    <= /div>
    Andy

    --001a11c2b61efbfb8404f7b6b22a-- From nobody Wed Apr 23 07:46: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 B53AD1A03C0 for ; Wed, 23 Apr 2014 07:46:10 -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 OlEPHzPKmRHa for ; Wed, 23 Apr 2014 07:46:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EE4101A0096 for ; Wed, 23 Apr 2014 07:46:09 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6AB1413F7DA; Wed, 23 Apr 2014 16:46:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398264363; bh=pzvZDC+XAaYnWO7K+r3OEmiT/ZTIUKaSDbHkh/T954A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EOxrbcWK9MXgVD5k4FuT3pjj9EYprqrdVspAZmq5oGMUsqghi2/PvGTuNCg6k1hJQ G0ef8GG7fZv/Q7VltL6YGuOI8UbWJfMQ51B2VhuOSJu1YxKSR21Qp6wB4MzlIlXRQ9 1gJEdjgwVL2CuL7UvpnhjmpNOD5eQNVw/euSbH5Y= 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:46:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140423.163410.854569166179772174.mbj@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/YtQuWRPf46eTkestHl6bA1EZlNw 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:46:10 -0000 On 23 Apr 2014, at 16:39, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Apr 23, 2014 at 7:34 AM, Martin Bjorklund = wrote: > Andy Bierman wrote: > > Don't put must-stmt in an empty NP container. >=20 > This isn't the issue. Here's an example of the problem: >=20 > container top { > presence "..."; > container foo { > must "a or b"; > leaf a { ... } > leaf b { ... } > } > } >=20 > When /top is created, we want a or b to exist. >=20 >=20 > So use the correct XPath: >=20 >=20 > container top { > presence "..."; > must "foo/a or foo/b"; > container foo { > leaf a { ... } > leaf b { ... } > } > } >=20 Well, that=92s an option, too. However, nothing in 6020 indicates that = Martin=92s version is incorrect. Lada > =20 > The behaviour is not clear from RFC 6020. We need to make this clear. >=20 > (I'll add this as a separate clarification issue) >=20 >=20 > /martin >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 23 08:04: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 66C981A03E0 for ; Wed, 23 Apr 2014 08:03:44 -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 2_Mq_BB4kQCi for ; Wed, 23 Apr 2014 08:03:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 083B71A0104 for ; Wed, 23 Apr 2014 08:03:30 -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 7BE5237C35E; Wed, 23 Apr 2014 17:03:23 +0200 (CEST) Date: Wed, 23 Apr 2014 17:03:23 +0200 (CEST) Message-Id: <20140423.170323.410297131277174843.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140423.163410.854569166179772174.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/mSwaZC-Ta1mzNXN26cOXwMjpCI0 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 15:03:45 -0000 Andy Bierman wrote: > On Wed, Apr 23, 2014 at 7:34 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > Don't put must-stmt in an empty NP container. > > > > This isn't the issue. Here's an example of the problem: > > > > container top { > > presence "..."; > > container foo { > > must "a or b"; > > leaf a { ... } > > leaf b { ... } > > } > > } > > > > When /top is created, we want a or b to exist. > > > > > So use the correct XPath: > > > container top { > presence "..."; > must "foo/a or foo/b"; > container foo { > leaf a { ... } > leaf b { ... } > } > } This is besides the point - the behavior of the construct above should be clear from the spec, don't you agree? /martin From nobody Wed Apr 23 08:11: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 4A02E1A03EE for ; Wed, 23 Apr 2014 08:11:03 -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 MEoJIHAjgcIr for ; Wed, 23 Apr 2014 08:11:01 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id CB46B1A03DC for ; Wed, 23 Apr 2014 08:10:53 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id ih12so995196qab.11 for ; Wed, 23 Apr 2014 08:10: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=+FDJpfzWsdsViau6CiWA2ekv34ffP3CNWghhTF7iPoU=; b=NHo5Jbh3y4i1nY36PGpIhFtkJRa+/uZz8t9ZWKyhdxzSCQRDHZZiwGmZUP9E8074RG yckoylm2PxuUur1hGzfYcrfA4KwfHyxN/DxdesnyaYkdwpMH6B0pfwd0n8APabkArueh IQCEhRoYE+HedUxhArk3ZNkOzn22A2Xg6XPzsG5eqa/FThkq5jqBMGhXKpAjqx2xR/N5 AFvf5rDzPLGa8siCKFrd33z0sxmtxD0LBwLlljatqkGrsRhfoRRL6JOJTdgQaGP3qC+7 nDe5gs3jKKhaQ8gg7cYLDO8gGhZ5965UPr7rXwNhseLSq2rmwr6GIuKhtF+J0ipKhW/c Qvww== X-Gm-Message-State: ALoCoQn7sHYnjWCUZ+4akzGTyJP7veQ/u9SrYnsKC5HMmu4j2y7vQp8uLEU4i4HnsgBzm5fatfhm MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr59355582qai.16.1398265847569; Wed, 23 Apr 2014 08:10:47 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 08:10:47 -0700 (PDT) In-Reply-To: <20140423.170323.410297131277174843.mbj@tail-f.com> References: <20140423.163410.854569166179772174.mbj@tail-f.com> <20140423.170323.410297131277174843.mbj@tail-f.com> Date: Wed, 23 Apr 2014 08:10:47 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c20e7a26009504f7b723b8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zFUbAC1zr3nztEsqsFGunpipdMw 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 15:11:03 -0000 --001a11c20e7a26009504f7b723b8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 8:03 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Apr 23, 2014 at 7:34 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > Don't put must-stmt in an empty NP container. > > > > > > This isn't the issue. Here's an example of the problem: > > > > > > container top { > > > presence "..."; > > > container foo { > > > must "a or b"; > > > leaf a { ... } > > > leaf b { ... } > > > } > > > } > > > > > > When /top is created, we want a or b to exist. > > > > > > > > So use the correct XPath: > > > > > > container top { > > presence "..."; > > must "foo/a or foo/b"; > > container foo { > > leaf a { ... } > > leaf b { ... } > > } > > } > > This is besides the point - the behavior of the construct above should > be clear from the spec, don't you agree? > > > Sure the text should always be 100% clear. My point is, the correct way to test for must constraints if container 'top' exists is to put the must-expr in container 'top'. The first must-stmt is just plain wrong if you want to test for foo/a or foo/b, when the parent node exists. > /martin > Andy --001a11c20e7a26009504f7b723b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 23, 2014 at 8:03 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    Andy Bierman <andy@yumaworks.com> wrote:
    > On Wed, Apr 23, 2014 at 7:34 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
    >
    > > Andy Bierman <andy@yumaw= orks.com> wrote:
    > > > Don't put must-stmt in an empty NP container.
    > >
    > > This isn't the issue. =A0Here's an example of the problem= :
    > >
    > > =A0 container top {
    > > =A0 =A0 presence "...";
    > > =A0 =A0 container foo {
    > > =A0 =A0 =A0 must "a or b";
    > > =A0 =A0 =A0 leaf a { ... }
    > > =A0 =A0 =A0 leaf b { ... }
    > > =A0 =A0 }
    > > =A0 }
    > >
    > > When /top is created, we want a or b to exist.
    > >
    > >
    > So use the correct XPath:
    >
    >
    > =A0container top {
    > =A0 =A0 presence "...";
    > =A0 =A0 must "foo/a or foo/b";
    > =A0 =A0 container foo {
    > =A0 =A0 =A0 leaf a { ... }
    > =A0 =A0 =A0 leaf b { ... }
    > =A0 =A0 }
    > =A0 }

    This is besides the point - the behavior of the construct above should
    be clear from the spec, don't you agree?




    Sure the = text should always be 100% clear.

    My point is, the= correct way to test for must constraints
    if container 'top&#= 39; exists is to put the must-expr in container 'top'.
    The first must-stmt is just plain wrong if you want to test for foo/a = or foo/b,
    when the parent node exists.

    <= br>

    =A0
    /martin

    Andy<= /div>

    --001a11c20e7a26009504f7b723b8-- From nobody Thu Apr 24 07:46: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 6E1EE1A031A for ; Thu, 24 Apr 2014 07:46:37 -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 v_0-d5MJfKEX for ; Thu, 24 Apr 2014 07:46:36 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 54BAD1A0318 for ; Thu, 24 Apr 2014 07:46:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D7013540680 for ; Thu, 24 Apr 2014 16:46:29 +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 2Okae1rxcIiP for ; Thu, 24 Apr 2014 16:46:19 +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 3CAE05402E5 for ; Thu, 24 Apr 2014 16:46:19 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 24 Apr 2014 16:46:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ywovv4E_5cmRwFJZuD1LPGw34tw Subject: [netmod] new issue: define the terms system/user-controlled instances 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, 24 Apr 2014 14:46:37 -0000 * Yxx: define the terms system/user-controlled instances ** Description The relationship between configuration and state data needs to be clarified. The terms system/user-controlled interfaces were coined in the interfaces-cfg draft and later adopted in the routing-cfg draft. It seems to be a general pattern so it should probably be addressed in YANG spec. ** Solution The definitions from sec. 4.1 in routing-cfg could be used, and an attribute introduced for tagging instances as system-controlled. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 24 07:58: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 08EA91A02A6 for ; Thu, 24 Apr 2014 07:58:46 -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 tTWPXrldqMfs for ; Thu, 24 Apr 2014 07:58:44 -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 2F9B41A01DC for ; Thu, 24 Apr 2014 07:58:44 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id j5so2680800qga.11 for ; Thu, 24 Apr 2014 07:58:38 -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=gYDaszos49VaFX8JLdJ5Badc3vQrg1X36Urr7rM7o2o=; b=Aw3ukmtDxIuwuoUtRlhLMRMyDiahdJAHf1MjG+SmWrwhKAs2sCq+qgTo0i2dPTMFgz +kCWWdSIquoNDoFye5oCGTRZF1nydZ1LqGXo3IgZMezA5y20wGFRx5Kmp0ALk1fMteb0 mFhAyyYGCOaRR08xirqutBFjzsKvQZVmBjcaNN8d5X2r53oKpPkOlj2+ToGYRaV2Ccc4 iKUJz2RPlLSmP/rO2fFsKH6mhrw/qgTnVVXkGL1UjTIIn6EmV1vDBTnoCrPwgT5jVRrm 0K4Pk96Ig95ZKlApv6QhFVKlThJGNFfWBL58OmDfFMH6FM+GAYZdWdaT08CpTo/w2pMm Q12A== X-Gm-Message-State: ALoCoQnAbcyFU0mR/pZDPkZo/CbMj8V03v4QCt4vAosf95IrPvzAZxeBq5xyuZZYTpWGg/0dv4Wt MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr3487181qai.16.1398351517990; Thu, 24 Apr 2014 07:58:37 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Thu, 24 Apr 2014 07:58:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 07:58:37 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c20e7a804cfe04f7cb1531 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HRgpmK-FbtrBvMWvQS-VX92ertU Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: define the terms system/user-controlled instances 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, 24 Apr 2014 14:58:46 -0000 --001a11c20e7a804cfe04f7cb1531 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 24, 2014 at 7:46 AM, Ladislav Lhotka wrote: > * Yxx: define the terms system/user-controlled instances > > ** Description > > The relationship between configuration and state data needs to be > clarified. The terms system/user-controlled interfaces were coined in > the interfaces-cfg draft and later adopted in the routing-cfg > draft. It seems to be a general pattern so it should probably be > addressed in YANG spec. > > ** Solution > > The definitions from sec. 4.1 in routing-cfg could be used, and an > attribute introduced for tagging instances as system-controlled. > > I agree this is an open issue, one that has been around since the start. I defined an extension years ago that allows clients to know in advance what will happen if they try to edit system-controlled data structures. (Also automates the server behavior). http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#user-write.663 I like the terminology "system controlled" and "user controlled", but sometimes it is not that simple (e.g. user can modify but not create or delete instances). Andy --001a11c20e7a804cfe04f7cb1531 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Thu, Apr 24, 2014 at 7:46 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
    * Yxx: define the terms system/user-controlled instances
    ** Description

    The relationship between configuration and state data needs to be
    clarified. The terms system/user-controlled interfaces were coined in
    the interfaces-cfg draft and later adopted in the routing-cfg
    draft. It seems to be a general pattern so it should probably be
    addressed in YANG spec.

    ** Solution

    The definitions from sec. 4.1 in routing-cfg could be used, and an
    attribute introduced for tagging instances as system-controlled.


    I agree this is an open issue, one that has been around si= nce the start.
    I defined an extension years ago that allows clien= ts to know in advance what
    will happen if they try to edit system-controlled data structures.
    (Also automates the server behavior).


    I like the terminology "system controlled" an= d "user controlled",
    but sometimes it is not that simpl= e (e.g. user can modify but not
    create or delete instances).



    Andy

    =
    --001a11c20e7a804cfe04f7cb1531-- From nobody Thu Apr 24 08:02: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 93C0B1A032D for ; Thu, 24 Apr 2014 08:02:19 -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 sdBkKosIR8AI for ; Thu, 24 Apr 2014 08:02: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 100D41A02A6 for ; Thu, 24 Apr 2014 08:02:18 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4D949141273; Thu, 24 Apr 2014 17:02:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398351731; bh=sxpTK9lTSTIfs9ikomQrTECzGZ3j/GjxmM0K94O05+s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nz1dTpg9BMZs00PXdwfmR4cDWR8l+tYu4a9lhgzIkeoL8oZ0vroKXoopVJuf4FR4C HbiIiEFNkMMOe93d8UhRGUnpCK0k0U2RKk5db0pyx3wYKzGEJX9Ubz++7b78s6JvRo InBt+rZDBrpRaYAGYjULrUIFZIMPrjFM2Mt7SCac= 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: Date: Thu, 24 Apr 2014 17:02:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CAAEA8A-3328-4193-8A31-3698B6DEB807@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/nww62i1tjaHjRakku6zDzw4u93I Cc: "netmod@ietf.org" Subject: Re: [netmod] new issue: define the terms system/user-controlled instances 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, 24 Apr 2014 15:02:19 -0000 On 24 Apr 2014, at 16:58, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Apr 24, 2014 at 7:46 AM, Ladislav Lhotka = wrote: > * Yxx: define the terms system/user-controlled instances >=20 > ** Description >=20 > The relationship between configuration and state data needs to be > clarified. The terms system/user-controlled interfaces were coined in > the interfaces-cfg draft and later adopted in the routing-cfg > draft. It seems to be a general pattern so it should probably be > addressed in YANG spec. >=20 > ** Solution >=20 > The definitions from sec. 4.1 in routing-cfg could be used, and an > attribute introduced for tagging instances as system-controlled. >=20 >=20 > I agree this is an open issue, one that has been around since the = start. > I defined an extension years ago that allows clients to know in = advance what > will happen if they try to edit system-controlled data structures. > (Also automates the server behavior). >=20 > = http://www.netconfcentral.org/modules/yuma-ncx/2013-05-25#user-write.663 >=20 > I like the terminology "system controlled" and "user controlled", > but sometimes it is not that simple (e.g. user can modify but not > create or delete instances). This has to be discussed, although I think this particular property is = already covered in the definition of a system-controlled entry. Lada >=20 >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 24 08:13: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 8757C1A0398 for ; Thu, 24 Apr 2014 08:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.333 X-Spam-Level: ** X-Spam-Status: No, score=2.333 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 JDR3xqhgCrt9 for ; Thu, 24 Apr 2014 08:13:08 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 594651A0397 for ; Thu, 24 Apr 2014 08:13:08 -0700 (PDT) Received: from [172.16.4.121] (fw.pantheon.sk [81.89.59.166]) by mail.hq.sk (Postfix) with ESMTPSA id 6311C26A for ; Thu, 24 Apr 2014 17:13:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1398352381; bh=UFV/+yZViUxBdFQO5M+Gp69KO13/L5a3DHAa0kqszBo=; h=Date:From:To:Subject; b=tVLOR746Kv+bl7a0o7j2J9R8KG8PmjNI3TU64Vg3AfxhS/gkeyP3inob7MBQ8Y2mM t1UMmfz67JbWVTJGESNuYU6bBKcmkbFuGx8jvUfV9uMxTicBzqsTvaenCq1dPyLcRC nL8NjBvZYL0hY5KKQGzluU+uycfc+pQqr2Sey5nE= Message-ID: <535929FD.9020503@hq.sk> Date: Thu, 24 Apr 2014 17:13:01 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cNmRyo-N5tnbuMVEn4fX01teK7A Subject: [netmod] new YANG 1.1 issue: support for IEEE754 types 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, 24 Apr 2014 15:13:10 -0000 Hi everyone, while modeling some protocols (notably RSVP), we came across the need to represent IEEE754-2008 floating types without losing precision. I'd like to ask what is the group's sentiment regarding extending the base types with at least binary{32,64} (which have their counterparts in XML schema datatypes). Thanks, Robert From nobody Thu Apr 24 08:20: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 E44EC1A037A for ; Thu, 24 Apr 2014 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, 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 gWJ9kdL3Hskf for ; Thu, 24 Apr 2014 08:20:54 -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 131FA1A036B for ; Thu, 24 Apr 2014 08:20:53 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so2642446qge.2 for ; Thu, 24 Apr 2014 08:20:47 -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=ptWrgmJ4p2TdHq/0QsToUAjbCFLXZaiG27KlEhQbJcs=; b=SU8S9YAtkl/09/gzdXAUHgcpnAIZWhShtoh8NICePJURBEK8YSTVWpPPgEVWt9QeC2 1uutHMuDR5NquguBekmQ2aSpVXr2foTsXG4qcQAq9/Q6cUvD3MjOA6PjcnBEuFYYBFS/ PJYaNhUIayXtFZx78Sy0EvHsH07LNY+hq474ZgttVxr1xLL4m+zTQejAoKIfR3Gi+zCP qA5MbzckMdwJtFUZtxtMkExSvPjy6m+6F1morRWJssiiBwq3MmtNfG/1rICUbdOaeubg 8Jh0DMJCvDJb7KdnIzT6EOjJU9Q5oRFXvO7Pd/bbtBEQUV8AFK/rArTMJOGCp75qBcjv Q2Tw== X-Gm-Message-State: ALoCoQl7GVaF7oK/JuEJ5VlWD16YwKsOWa/6ynqkja4saDkZK4OhfvALPVKgocC2kwRyt+Mjw48u MIME-Version: 1.0 X-Received: by 10.140.18.173 with SMTP id 42mr3401966qgf.94.1398352847657; Thu, 24 Apr 2014 08:20:47 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Thu, 24 Apr 2014 08:20:47 -0700 (PDT) In-Reply-To: <535929FD.9020503@hq.sk> References: <535929FD.9020503@hq.sk> Date: Thu, 24 Apr 2014 08:20:47 -0700 Message-ID: From: Andy Bierman To: Robert Varga Content-Type: multipart/alternative; boundary=001a11351cb2c184f104f7cb64cd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/r2lG3GCzX9xx7qpWvkDdUw3C56o Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 issue: support for IEEE754 types 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, 24 Apr 2014 15:20:55 -0000 --001a11351cb2c184f104f7cb64cd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 24, 2014 at 8:13 AM, Robert Varga wrote: > Hi everyone, > > while modeling some protocols (notably RSVP), we came across the need to > represent IEEE754-2008 floating types without losing precision. I'd like to > ask what is the group's sentiment regarding extending the base types with > at least binary{32,64} (which have their counterparts in XML schema > datatypes). > > YANG originally had float32 and float64 types. Networking vendors objected to mandatory floating-point support as being too heavy-weight. (I tend to agree). Our code still has float64 support because XPath needs it. I think you could define these types with typedefs, which would make them optional to implement. Thanks, > Robert > Andy --001a11351cb2c184f104f7cb64cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Thu, Apr 24, 2014 at 8:13 AM, Robert Varga <= ;nite@hq.sk> = wrote:
    Hi everyone,

    while modeling some protocols (notably RSVP), we came across the need to re= present IEEE754-2008 floating types without losing precision. I'd like = to ask what is the group's sentiment regarding extending the base types= with at least binary{32,64} (which have their counterparts in XML schema d= atatypes).


    YANG originally had float32 and float6= 4 types.
    Networking vendors objected to mandatory floating-point = support
    as being too heavy-weight. (I tend to agree).

    Our code still has float64 support because XPath needs it.
    I think you could define these types with typedefs, which would ma= ke
    them optional to implement.


    Thanks,
    Robert

    Andy
    =A0
    --001a11351cb2c184f104f7cb64cd-- From nobody Thu Apr 24 13: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 CDEA01A03E2 for ; Thu, 24 Apr 2014 13:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.699 X-Spam-Level: *** X-Spam-Status: No, score=3.699 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, 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 S5tGCstRoG_c for ; Thu, 24 Apr 2014 13:40:59 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 517B11A03D9 for ; Thu, 24 Apr 2014 13:40:59 -0700 (PDT) Received: from [172.16.0.226] (chello085216150117.chello.sk [85.216.150.117]) by mail.hq.sk (Postfix) with ESMTPSA id 93C0D2B3; Thu, 24 Apr 2014 22:40:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1398372051; bh=W0cxte2cRtOMUwafUtPF/Cp9FKOiedkcwUxad7fZMe4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=tsq2lNF8aj8pb0NG4DrJtuoozb75+hFqpTi8wBhm4QHLJIl1XFR2y+bQJDwgSmsym WLYe4BE4enMOSfOYzH9tsb/Zj/c6+/ci9BtRVpsyJWHaB7lmyEIjts59f/OqgWANPo 9q19W7w+PsXnbhtIhwjuO7+cXQBm8mz3BlYZ4Ph8= Message-ID: <535976D3.7000003@hq.sk> Date: Thu, 24 Apr 2014 22:40:51 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Bierman References: <535929FD.9020503@hq.sk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060202080609080909070307" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QpyTbXCMIVhPZmaMcwoS1_GkIjc Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 issue: support for IEEE754 types 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, 24 Apr 2014 20:41:02 -0000 This is a multi-part message in MIME format. --------------060202080609080909070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/24/2014 05:20 PM, Andy Bierman wrote: > On Thu, Apr 24, 2014 at 8:13 AM, Robert Varga > wrote: > > Hi everyone, > > while modeling some protocols (notably RSVP), we came across the > need to represent IEEE754-2008 floating types without losing > precision. I'd like to ask what is the group's sentiment regarding > extending the base types with at least binary{32,64} (which have > their counterparts in XML schema datatypes). > > > YANG originally had float32 and float64 types. > Networking vendors objected to mandatory floating-point support > as being too heavy-weight. (I tend to agree). Can you elaborate on where the weight is coming from? It seems to me that this is not necessarily a concern on network devices, as they provide the models, so they do not need to support floating types if they don't use them. Furthermore, I don't think having a base type implies having an arithmetic unit capable of working on it -- it's just the ability to store the value. > > Our code still has float64 support because XPath needs it. > I think you could define these types with typedefs, which would make > them optional to implement. I think we've done precisely what you're suggesting for OpenDaylight ( https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=concepts/src/main/yang/ieee754.yang;hb=HEAD ): typedef float32 { type binary { length 4; } } The problem with this approach is that it does not play nicely with RESTCONF, as the binary base type forces BASE-64 encoding, which confuses users, who expect bandwidth (specifically) to be a number, not a bunch of characters. Another solution to this would be to standardize the typedef definition and have RESTCONF draft provide a special-case handling for these types. Thanks, Robert --------------060202080609080909070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    On 04/24/2014 05:20 PM, Andy Bierman wrote:
    On Thu, Apr 24, 2014 at 8:13 AM, Robert Varga <nite@hq.sk> wrote:
    Hi everyone,

    while modeling some protocols (notably RSVP), we came across the need to represent IEEE754-2008 floating types without losing precision. I'd like to ask what is the group's sentiment regarding extending the base types with at least binary{32,64} (which have their counterparts in XML schema datatypes).


    YANG originally had float32 and float64 types.
    Networking vendors objected to mandatory floating-point support
    as being too heavy-weight. (I tend to agree).

    Can you elaborate on where the weight is coming from?

    It seems to me that this is not necessarily a concern on network devices, as they provide the models, so they do not need to support floating types if they don't use them. Furthermore, I don't think having a base type implies having an arithmetic unit capable of working on it -- it's just the ability to store the value.


    Our code still has float64 support because XPath needs it.
    I think you could define these types with typedefs, which would make
    them optional to implement.

    I think we've done precisely what you're suggesting for OpenDaylight ( https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=concepts/src/main/yang/ieee754.yang;hb=HEAD ):

            typedef float32 {
		type binary {
			length 4;
		}
	}

    The problem with this approach is that it does not play nicely with RESTCONF, as the binary base type forces BASE-64 encoding, which confuses users, who expect bandwidth (specifically) to be a number, not a bunch of characters.

    Another solution to this would be to standardize the typedef definition and have RESTCONF draft provide a special-case handling for these types.

    Thanks,
    Robert

    --------------060202080609080909070307-- From nobody Thu Apr 24 14:02:27 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 5150E1A03E2 for ; Thu, 24 Apr 2014 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 pV0825kj4eEt for ; Thu, 24 Apr 2014 14:02:21 -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 C97581A0389 for ; Thu, 24 Apr 2014 14:02:20 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so3156759qcy.14 for ; Thu, 24 Apr 2014 14:02: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=VfOVWGNfIumomvJbYiJ+DMg3Qt91FiM93ljCyEe2qww=; b=Gi+7pd7aiwAQNj04k+uw132ATWRGk7EqK39vm2JXJqOEHq4bhVZYKFJfdTCg3W44p6 kqSHyBionx5x8ENxYKjxqb3bmKwFJoZznJctrZdZjiKKaEbZHIVPGpqUprbCNnwZpfhW QESCo2sGU0XTE5Rml94Ye+lDquOCT5Ig3lrJnyukRWyrt/r/rRPsv81ZKVxQcZs0P9iJ km/tRpVwUcyWcpk14UfOUeBd5b6Nt7IoIZ3Vioyc0/rGZOQL02kTXsJts11AAR3ffBh2 S5LpSAMCXzswpdxh1OljrVIySJyiqSOcNVS2xSui1eDbHxPIapr5Dw9LKKC+14a4v/fL ZjFw== X-Gm-Message-State: ALoCoQmFovyPAOqhDjnuTs65g5jRVe2hRPgI4s/lzbRYoASvSW0ZqwA/nEvmJm6kI3Zh+XwNn1Bx MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr5950784qge.34.1398373334184; Thu, 24 Apr 2014 14:02:14 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Thu, 24 Apr 2014 14:02:14 -0700 (PDT) In-Reply-To: <535976D3.7000003@hq.sk> References: <535929FD.9020503@hq.sk> <535976D3.7000003@hq.sk> Date: Thu, 24 Apr 2014 14:02:14 -0700 Message-ID: From: Andy Bierman To: Robert Varga Content-Type: multipart/alternative; boundary=001a113abfd8d9148804f7d029e3 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R6NVM4KwprQC8tjqLvt1YZTPPdw Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 issue: support for IEEE754 types 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, 24 Apr 2014 21:02:24 -0000 --001a113abfd8d9148804f7d029e3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 24, 2014 at 1:40 PM, Robert Varga wrote: > On 04/24/2014 05:20 PM, Andy Bierman wrote: > > On Thu, Apr 24, 2014 at 8:13 AM, Robert Varga wrote: > >> Hi everyone, >> >> while modeling some protocols (notably RSVP), we came across the need to >> represent IEEE754-2008 floating types without losing precision. I'd like to >> ask what is the group's sentiment regarding extending the base types with >> at least binary{32,64} (which have their counterparts in XML schema >> datatypes). >> >> > YANG originally had float32 and float64 types. > Networking vendors objected to mandatory floating-point support > as being too heavy-weight. (I tend to agree). > > > Can you elaborate on where the weight is coming from? > > Floating point is rarely needed. The WG decided to use decimal64 instead. > It seems to me that this is not necessarily a concern on network devices, > as they provide the models, so they do not need to support floating types > if they don't use them. Furthermore, I don't think having a base type > implies having an arithmetic unit capable of working on it -- it's just the > ability to store the value. > > > Our code still has float64 support because XPath needs it. > I think you could define these types with typedefs, which would make > them optional to implement. > > > I think we've done precisely what you're suggesting for OpenDaylight ( > https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=concepts/src/main/yang/ieee754.yang;hb=HEAD): > > typedef float32 { > type binary { > length 4; > } > } > > > The problem with this approach is that it does not play nicely with > RESTCONF, as the binary base type forces BASE-64 encoding, which confuses > users, who expect bandwidth (specifically) to be a number, not a bunch of > characters. > > Another solution to this would be to standardize the typedef definition > and have RESTCONF draft provide a special-case handling for these types. > > I don't want RESTCONF to use a different YANG language than other protocols. This is a very minor issue. Why do humans need to look at the encoding? RESTCONF is supposed to be a programmatic API. You could use type string if you really wanted to make the encoding readable. > Thanks, > Robert > > Andy --001a113abfd8d9148804f7d029e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Thu, Apr 24, 2014 at 1:40 PM, Robert Varga <= ;nite@hq.sk> = wrote:
    =20 =20 =20


    =A0
    It seems to me that this is not necessarily a concern on network devices, as they provide the models, so they do not need to support floating types if they don't use them. Furthermore, I don't thi= nk having a base type implies having an arithmetic unit capable of working on it -- it's just the ability to store the value.


    Our code still has float64 support because XPath needs it.
    I think you could define these types with typedefs, which would make
    them optional to implement.

    I think we've done precisely what you're suggesting for OpenDay= light (     https://git.opendaylight.org/gerrit/gitweb?p=3Dbgpcep.git;a=3Dblob_= plain;f=3Dconcepts/src/main/yang/ieee754.yang;hb=3DHEAD ):

            typedef float32 {
		type binary {
			length 4;
		}
	}

    The problem with this approach is that it does not play nicely with RESTCONF, as the binary base type forces BASE-64 encoding, which confuses users, who expect bandwidth (specifically) to be a number, not a bunch of characters.

    Another solution to this would be to standardize the typedef definition and have RESTCONF draft provide a special-case handling for these types.


    I don't want RESTCONF to= use a different YANG language than other protocols.
    This is a ve= ry minor issue. =A0Why do humans need to look at the encoding?
    RESTCONF is supposed to be a programmatic API.

    You= could use type string if you really wanted to make the encoding readable.<= /div>

    =A0
    Thanks,
    Robert



    Andy

    --001a113abfd8d9148804f7d029e3-- From nobody Thu Apr 24 23:39: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 AAAAE1A0438 for ; Thu, 24 Apr 2014 23: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 SehOsueGdSQU for ; Thu, 24 Apr 2014 23:39:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC131A032F for ; Thu, 24 Apr 2014 23:39:07 -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 25727240C39D; Fri, 25 Apr 2014 08:39:00 +0200 (CEST) Date: Fri, 25 Apr 2014 08:38:59 +0200 (CEST) Message-Id: <20140425.083859.207155891530348322.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <535976D3.7000003@hq.sk> 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/YW4vbw4vKxeACxNFfBKL246ANOk Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: support for IEEE754 types 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, 25 Apr 2014 06:39:08 -0000 Andy Bierman wrote: > Floating point is rarely needed. > The WG decided to use decimal64 instead. +1. We had long discussions about this - search the archives for "float" around 2008/2009. A proposal for adding these types back should have answers for the problems we found that got us to remove them. /martin From nobody Fri Apr 25 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 D56951A0328 for ; Fri, 25 Apr 2014 00:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, 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 TwOlT51gMW8D for ; Fri, 25 Apr 2014 00:40:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 89EEC1A0311 for ; Fri, 25 Apr 2014 00:40:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9067B119A for ; Fri, 25 Apr 2014 09:40:02 +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 FsqBcUNoGONW for ; Fri, 25 Apr 2014 09:40:01 +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 for ; Fri, 25 Apr 2014 09:40:01 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD9442002C for ; Fri, 25 Apr 2014 09:40:01 +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 N5jQycHg9uGK; Fri, 25 Apr 2014 09:40:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07C5620013; Fri, 25 Apr 2014 09:40:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EBD622CAB3D1; Fri, 25 Apr 2014 09:40:00 +0200 (CEST) Date: Fri, 25 Apr 2014 09:40:00 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140425074000.GA8182@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/onCcpXg7T627-JmQHtrtuAS3ib4 Subject: [netmod] closing yang 1.1 open issue list on 2014-05-07 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, 25 Apr 2014 07:40:12 -0000 Hi, we have been collecting issues to be considered for YANG 1.1 since March 23rd and the WG charter covering the YANG 1.1 work was approved on April 11th. The current list of issues can be found here (38 issues right now): http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.txt http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html The chairs like to close the YANG 1.1 issue collection phase on May 7th (2014-05-07). After this deadline, we will only add issues in exceptional cases. So please post any remaining issues you want to have addressed within the next couple of days: > For discussion of the issues, please use mailing list threads that > include the issue identifier. For new issues that you want to open, > start a new thread on the mailing list to define the issue. Martin > will double check that submitted new issues will not repeat or overlap > with existing issues (if so, he will respond on the mailing list > thread). After May 7th, we will run a process to decide which issues will be accepted as in scope for YANG 1.1 (that is move issues from NEW to either OPEN or DEAD). /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 25 01:04: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 6C95B1A0479 for ; Fri, 25 Apr 2014 01:04:38 -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 wAv3AABW6oFF for ; Fri, 25 Apr 2014 01:04:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 788951A01B7 for ; Fri, 25 Apr 2014 01:04:35 -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 70E363941C6; Fri, 25 Apr 2014 10:04:28 +0200 (CEST) Date: Fri, 25 Apr 2014 10:04:28 +0200 (CEST) Message-Id: <20140425.100428.10446365836123151.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/KJ1r2S13xGU9EAA9PwGDka9Srl4 Cc: netmod@ietf.org Subject: Re: [netmod] new issue: define the terms system/user-controlled instances 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, 25 Apr 2014 08:04:39 -0000 Hi, Added as Y39. /martin Ladislav Lhotka wrote: > * Yxx: define the terms system/user-controlled instances > > ** Description > > The relationship between configuration and state data needs to be > clarified. The terms system/user-controlled interfaces were coined in > the interfaces-cfg draft and later adopted in the routing-cfg > draft. It seems to be a general pattern so it should probably be > addressed in YANG spec. > > ** Solution > > The definitions from sec. 4.1 in routing-cfg could be used, and an > attribute introduced for tagging instances as system-controlled. > > -- > 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 25 01:05: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 90AB21A0478 for ; Fri, 25 Apr 2014 01:04:52 -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 iGWoT_A_yL5G for ; Fri, 25 Apr 2014 01:04:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 598C61A00DC for ; Fri, 25 Apr 2014 01:04:49 -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 A7D1E574003; Fri, 25 Apr 2014 10:04:42 +0200 (CEST) Date: Fri, 25 Apr 2014 10:04:42 +0200 (CEST) Message-Id: <20140425.100442.720926568697698876.mbj@tail-f.com> To: nite@hq.sk From: Martin Bjorklund In-Reply-To: <535929FD.9020503@hq.sk> References: <535929FD.9020503@hq.sk> 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/AQH58GCrWH57tEtdZgK3lr1EEBk Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: support for IEEE754 types 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, 25 Apr 2014 08:04:52 -0000 Hi, Added as Y40. /martin Robert Varga wrote: > Hi everyone, > > while modeling some protocols (notably RSVP), we came across the need > to represent IEEE754-2008 floating types without losing precision. I'd > like to ask what is the group's sentiment regarding extending the base > types with at least binary{32,64} (which have their counterparts in > XML schema datatypes). > > Thanks, > Robert > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Apr 25 01:07: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 5BB821A0479 for ; Fri, 25 Apr 2014 01:06:55 -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 APArfUSyfJBT for ; Fri, 25 Apr 2014 01:06:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 55A721A047D for ; Fri, 25 Apr 2014 01:06:26 -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 D45D63941C6 for ; Fri, 25 Apr 2014 10:06:18 +0200 (CEST) Date: Fri, 25 Apr 2014 10:06:18 +0200 (CEST) Message-Id: <20140425.100618.233149138215462456.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20140425074000.GA8182@elstar.local> References: <20140425074000.GA8182@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/bOjrp363vuPorACNjCYpH5XqbVw Subject: Re: [netmod] closing yang 1.1 open issue list on 2014-05-07 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, 25 Apr 2014 08:06:55 -0000 Juergen Schoenwaelder wrote: > Hi, > > we have been collecting issues to be considered for YANG 1.1 since > March 23rd and the WG charter covering the YANG 1.1 work was approved > on April 11th. The current list of issues can be found here (38 issues > right now): > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.txt > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html If someone has suggested an issue that I haven't added, please let me know. I might have missed some issues. /martin From nobody Fri Apr 25 01:25: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 860861A0491 for ; Fri, 25 Apr 2014 01:25:00 -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 DKpAf3VTPuPY for ; Fri, 25 Apr 2014 01:24: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 05E921A047A for ; Fri, 25 Apr 2014 01:24:56 -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 09E173941A7; Fri, 25 Apr 2014 10:24:50 +0200 (CEST) Message-ID: <535A1BD1.6040001@tail-f.com> Date: Fri, 25 Apr 2014 10:24:49 +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: <20140425074000.GA8182@elstar.local> <20140425.100618.233149138215462456.mbj@tail-f.com> In-Reply-To: <20140425.100618.233149138215462456.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/NsXam9Dc_trtC7-YwiTk5l8Yd58 Cc: netmod@ietf.org Subject: Re: [netmod] closing yang 1.1 open issue list on 2014-05-07 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, 25 Apr 2014 08:25:00 -0000 On 2014-04-25 10:06, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> Hi, >> >> we have been collecting issues to be considered for YANG 1.1 since >> March 23rd and the WG charter covering the YANG 1.1 work was approved >> on April 11th. The current list of issues can be found here (38 issues >> right now): >> >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.txt >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html > > If someone has suggested an issue that I haven't added, please let me > know. I might have missed some issues. It seems that you didn't add "clarification of 'must' in np-container" as a separate issue from "add 'mandatory' to NP-container" (Y38). I believe it is important to address the former even if the latter is dropped, since there seems to be significant disagreement on what it actually means. Side note: both suggested solutions to Y38 are labeled Y38-01. --Per From nobody Fri Apr 25 01:50: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 90F8F1A02D0 for ; Fri, 25 Apr 2014 01:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 YmYsZZ247a2u for ; Fri, 25 Apr 2014 01:50:17 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id B00F91A00FF for ; Fri, 25 Apr 2014 01:50:16 -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 s3P8o9di027406 for ; Fri, 25 Apr 2014 10:50:09 +0200 Message-ID: <535A21C0.9000901@mg-soft.com> Date: Fri, 25 Apr 2014 10:50:08 +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: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qieMDCJPH5EuyfNZtBHms3pUfpw Subject: [netmod] new YANG 1.1 issue: unsolved grammar bugs 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, 25 Apr 2014 08:50:19 -0000 Hi, here are some old threads that could be resolved in 1.1. Not sure if anyone was tracking those, or if the related issues are applicable. There is a confirmed bug in YANG grammar for which no errata has been posted yet. The current grammar requires unquoted strings as arguments to deviate statements. http://www.ietf.org/mail-archive/web/netmod/current/msg07738.html Ambiguity of refine-stmt production was also mentioned. http://www.ietf.org/mail-archive/web/netmod/current/msg07740.html There was also a discussion about the unknown-statement2 production, which implied a need for clarification of it's meaning. http://www.ietf.org/mail-archive/web/netmod/current/msg08148.html Jernej From nobody Fri Apr 25 02:05: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 A51221A0291 for ; Fri, 25 Apr 2014 02:05:24 -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 oYsl9n4i3DBX for ; Fri, 25 Apr 2014 02:05:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 945AE1A020C for ; Fri, 25 Apr 2014 02:05:21 -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 1D01F3941B4; Fri, 25 Apr 2014 11:05:14 +0200 (CEST) Date: Fri, 25 Apr 2014 11:05:12 +0200 (CEST) Message-Id: <20140425.110512.318435752551940586.mbj@tail-f.com> To: per@tail-f.com From: Martin Bjorklund In-Reply-To: <535A1BD1.6040001@tail-f.com> References: <20140425074000.GA8182@elstar.local> <20140425.100618.233149138215462456.mbj@tail-f.com> <535A1BD1.6040001@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/JnNNaZFJerC4iQpCbOXVfuNLNz0 Cc: netmod@ietf.org Subject: Re: [netmod] closing yang 1.1 open issue list on 2014-05-07 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, 25 Apr 2014 09:05:24 -0000 Per Hedeland wrote: > On 2014-04-25 10:06, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > >> Hi, > >> > >> we have been collecting issues to be considered for YANG 1.1 since > >> March 23rd and the WG charter covering the YANG 1.1 work was approved > >> on April 11th. The current list of issues can be found here (38 issues > >> right now): > >> > >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.txt > >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html > > > > If someone has suggested an issue that I haven't added, please let me > > know. I might have missed some issues. > > It seems that you didn't add "clarification of 'must' in np-container" > as a separate issue from "add 'mandatory' to NP-container" (Y38). I > believe it is important to address the former even if the latter is > dropped, since there seems to be significant disagreement on what it > actually means. Agreed; added as Y41. > Side note: both suggested solutions to Y38 are labeled Y38-01. Fixed. /martin From nobody Fri Apr 25 03:53: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 326251A03A6 for ; Fri, 25 Apr 2014 03:53:53 -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 ij12w4B-bpyj for ; Fri, 25 Apr 2014 03:53:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2965B1A0366 for ; Fri, 25 Apr 2014 03:53:51 -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 6BB593941A8; Fri, 25 Apr 2014 12:53:43 +0200 (CEST) Date: Fri, 25 Apr 2014 12:53:43 +0200 (CEST) Message-Id: <20140425.125343.926843104726921748.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <535A21C0.9000901@mg-soft.com> References: <535A21C0.9000901@mg-soft.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/vBTCZw_fM6Tk_xjuJuJzv8GeIVY Cc: netmod@ietf.org Subject: Re: [netmod] new YANG 1.1 issue: unsolved grammar bugs 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, 25 Apr 2014 10:53:53 -0000 Jernej Tuljak wrote: > Hi, > > here are some old threads that could be resolved in 1.1. Not sure if > anyone was tracking those, or if the related issues are applicable. These were not tracked, thank's for reminding me! > There is a confirmed bug in YANG grammar for which no errata has been > posted yet. The current grammar requires unquoted strings as arguments > to deviate statements. > http://www.ietf.org/mail-archive/web/netmod/current/msg07738.html I have fixed this bug in the to-be-posted 6020bis draft. > Ambiguity of refine-stmt production was also mentioned. > http://www.ietf.org/mail-archive/web/netmod/current/msg07740.html > > There was also a discussion about the unknown-statement2 production, > which implied a need for clarification of it's meaning. > http://www.ietf.org/mail-archive/web/netmod/current/msg08148.html I think that we can simply do these grammar changes directly without listing them in the issues file. They don't change anything to the language, they merely make the grammar better. Unless someone objects, I'll make the changes. People still have to review the document and we might decide that the old version was better; that is ok of course. /martin From nobody Mon Apr 28 00:04:01 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 5A1BF1A0447 for ; Mon, 28 Apr 2014 00:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 e0yZ4tQnSz5e for ; Mon, 28 Apr 2014 00:03:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AC8441A0269 for ; Mon, 28 Apr 2014 00:03:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2970A54061D; Mon, 28 Apr 2014 09:03:52 +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 UQikuMdbC-6G; Mon, 28 Apr 2014 09:03: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 796E6540394; Mon, 28 Apr 2014 09:03:46 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20140425.100618.233149138215462456.mbj@tail-f.com> References: <20140425074000.GA8182@elstar.local> <20140425.100618.233149138215462456.mbj@tail-f.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 28 Apr 2014 09:03:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i6PnbBzRleZnomtvWBKpm6VvlU8 Subject: Re: [netmod] closing yang 1.1 open issue list on 2014-05-07 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, 28 Apr 2014 07:03:57 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> Hi, >> >> we have been collecting issues to be considered for YANG 1.1 since >> March 23rd and the WG charter covering the YANG 1.1 work was approved >> on April 11th. The current list of issues can be found here (38 issues >> right now): >> >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.txt >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html > > If someone has suggested an issue that I haven't added, please let me > know. I might have missed some issues. I am not sure about this one: http://www.ietf.org/mail-archive/web/netmod/current/msg09597.html It is related to Y39 but the scope is broader. I guess the essential question is whether it is really a good idea to define 'config false' data in the subtree of a 'config true' node - see the recent discussion in I2RS. Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 28 00:53: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 011021A08B0 for ; Mon, 28 Apr 2014 00:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 HL9Vw63c9Vyj for ; Mon, 28 Apr 2014 00:53:18 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 820A91A0770 for ; Mon, 28 Apr 2014 00:53:18 -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 478F8574001; Mon, 28 Apr 2014 09:53:16 +0200 (CEST) Date: Mon, 28 Apr 2014 09:53:15 +0200 (CEST) Message-Id: <20140428.095315.1269494981032582047.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20140425074000.GA8182@elstar.local> <20140425.100618.233149138215462456.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/wLiRDzS3YVB7EzMVSiZN1zJ0_Y0 Cc: netmod@ietf.org Subject: Re: [netmod] closing yang 1.1 open issue list on 2014-05-07 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, 28 Apr 2014 07:53:20 -0000 Ladislav Lhotka wrote: > I am not sure about this one: > > http://www.ietf.org/mail-archive/web/netmod/current/msg09597.html > > It is related to Y39 but the scope is broader. I guess the essential > question is whether it is really a good idea to define 'config > false' data in the subtree of a 'config true' node - see the recent > discussion in I2RS. Ok, added as Y42. /martin From nobody Mon Apr 28 00:55: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 C5B501A08B0 for ; Mon, 28 Apr 2014 00:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 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.651] 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 cNewlCtlx1nv for ; Mon, 28 Apr 2014 00:55:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 18BA31A0767 for ; Mon, 28 Apr 2014 00:55:29 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7470413FCDE; Mon, 28 Apr 2014 09:55:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398671728; bh=Zj5vOw+RNBq95R9veH7xu9ZnKLLazuHCgmnLCYTETss=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IrbqNHXzpqcGbFqgCnf+R0Bd7GrDZ/N+z3gesf35T51KJiPwdCGpZcxRc1cJLT9YE X18ccJwobGjMaI5SS0AfmMJMxdPwn0jgb7E2jZQxMObafmnt3ldusVXJ26/s/Cj8Pj nPTevVS98FaojoaUOhhFURg8570CpXhsmkpWXYJI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140428.095315.1269494981032582047.mbj@tail-f.com> Date: Mon, 28 Apr 2014 09:55:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: <82FEEABD-7D0D-4D6F-8C53-571288550662@nic.cz> References: <20140425074000.GA8182@elstar.local> <20140425.100618.233149138215462456.mbj@tail-f.com> <20140428.095315.1269494981032582047.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/KTQCHXV7nNTB2OD8x2TezZuqBbI Cc: netmod@ietf.org Subject: Re: [netmod] closing yang 1.1 open issue list on 2014-05-07 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, 28 Apr 2014 07:55:32 -0000 On 28 Apr 2014, at 09:53, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> I am not sure about this one: >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg09597.html >> >> It is related to Y39 but the scope is broader. I guess the essential >> question is whether it is really a good idea to define 'config >> false' data in the subtree of a 'config true' node - see the recent >> discussion in I2RS. > > Ok, added as Y42. Great, the number tells you something. :-) Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 28 02:46: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 210781A08C1 for ; Mon, 28 Apr 2014 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] 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 IZ7jmjuPfXdd for ; Mon, 28 Apr 2014 02:46:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9771A0857 for ; Mon, 28 Apr 2014 02:46:10 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id DD3115BFBCB for ; Mon, 28 Apr 2014 17:45:54 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s3S9jtro005720 for ; Mon, 28 Apr 2014 17:45:55 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) To: netmod@ietf.org MIME-Version: 1.0 X-KeepSent: 5D298254:EB92C40F-48257CC8:0032751B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 28 Apr 2014 17:45:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-04-28 17:45:58, Serialize complete at 2014-04-28 17:45:58 Content-Type: multipart/alternative; boundary="=_alternative 0035A53B48257CC8_=" X-MAIL: mse02.zte.com.cn s3S9jtro005720 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ohP9S8LGQkNuhfN7heE50S54JSQ Subject: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 09:46:24 -0000 This is a multipart message in MIME format. --=_alternative 0035A53B48257CC8_= Content-Type: text/plain; charset="US-ASCII" Hi all, I suggest add 'exception' statement to make 'error-app-tag' and 'error-message' can be reused and make it possible to express multi 'error-app-tag' or 'error-msg'. 'exception' statement can be mapped to 'rpc-error'element in NETCONF. exception statement's sub statement: +---------------+-------------+ | substatement | cardinality | +---------------+-------------+ | description | 0..1 | | error-app-tag | 0..1 | | error-message | 0..1 | | reference | 0..1 | +---------------+-------------+ For example: exception foo { error-app-tag "abc"; error-message "This is just a example"; } and add 'throws' statement as must's substatement. For example : must "a > b or a < 1500" { throws foo; } btw: 'throws' statement can be used to declare a exception may be thrown. if a 'must' expression may throw multi exceptions, the example is listed below: must "a > b or a < 1500" { throws foo1; throws foo2; } If a exception statement has no error-app-tag and error-message, it means any exception may be thrown. I also suggest add 'throws' ,'error-app-tag' and 'error-message' statements to 'rpc' statement, it can indicate which exception may be thrown. User who execute rpc operation can be easy to handle 'rpc-error'. rpc's subsatatment: +--------------+-------------+ | substatement | cardinality | +--------------+-------------+ | description | 0..1 | | grouping | 0..n | | if-feature | 0..n | | input | 0..1 | | output | 0..1 | | reference | 0..1 | | status | 0..1 | | typedef | 0..n | | error-app-tag| 0..1 | | error-message| 0..1 | | throws | 0..n | +--------------+-------------+ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0035A53B48257CC8_= Content-Type: text/html; charset="US-ASCII" Hi all,
          I suggest add 'exception' statement to make 'error-app-tag' and 'error-message' can be reused and make it possible to express multi 'error-app-tag' or 'error-msg'.
          'exception' statement can be mapped to 'rpc-error'element in NETCONF.
          exception statement's sub statement:
                     +---------------+-------------+
                     | substatement  | cardinality |
                     +---------------+-------------+
                     | description   | 0..1        |
                     | error-app-tag | 0..1        |
                     | error-message | 0..1        |
                     | reference     | 0..1        |
                     +---------------+-------------+
          For example:
          exception  foo {
               error-app-tag "abc";
               error-message "This is just a example";
          }

          and add 'throws' statement as must's substatement.
         
          For example :
          must "a > b or a < 1500" {
               throws foo;
          }
         
          btw: 'throws' statement can be used to declare a exception may be thrown.

          if a 'must' expression may throw multi exceptions, the example is listed below:
         
          must "a > b or a < 1500" {
                throws foo1;
                throws foo2;
          }
         
          If a exception statement has no error-app-tag and error-message, it means any exception may be thrown.

    I also suggest add 'throws' ,'error-app-tag' and 'error-message' statements to 'rpc' statement, it can indicate which exception may be thrown.

    User who execute rpc operation can be easy to handle 'rpc-error'.
          rpc's subsatatment:
                     +--------------+-------------+
                     | substatement | cardinality |
                     +--------------+-------------+
                     | description  | 0..1        |
                     | grouping     | 0..n        |
                     | if-feature   | 0..n        |
                     | input        | 0..1        |
                     | output       | 0..1        |
                     | reference    | 0..1        |
                     | status       | 0..1        |
                     | typedef      | 0..n        |
                     | error-app-tag| 0..1        |
                     | error-message| 0..1        |
                     | throws       | 0..n        |
                     +--------------+-------------+ 
    
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

    --=_alternative 0035A53B48257CC8_=-- From nobody Mon Apr 28 07:27: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 18F3B1A0983 for ; Mon, 28 Apr 2014 07:27: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 wwvaI1zI7bq8 for ; Mon, 28 Apr 2014 07:27:52 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28A611A047E for ; Mon, 28 Apr 2014 07:27:52 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id k15so1517730qaq.31 for ; Mon, 28 Apr 2014 07:27: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=T5MR3jBUSuJKqj+X1cdpqmC0i9RSJhZ7VxHMArYY4tU=; b=LR2Y3jTPhjbgWQvPknVUW1oNVPgm6LLVnAy6l5eA6szT/WJ9vYzH/uPab0rPzXhHme 29NsFmVbWhpVuy1ZlJgLbgSCc/tlot0W97juxyC0EnUfN3KaLzfM7IiuzDXyPWqtAuI2 pT53mghEDrgIYVWo6FpQvFnHxhE04jDrkI17eMHrHSPSysDm4b7l0WTWcjvGJQp9Nq+V 0M8W3JYpPyNfLHLYemV7zZWRdMXloUrtCJi9vTzSSuojEy8Li/f+gJz2EgCipZ32Gz3e gCpdb8lxIXw6VZdTA6shD2nRKoJG0KZrg/8LdZVR8AdzSbWXv4ItlMnYaHoJx27P09br GvWw== X-Gm-Message-State: ALoCoQlBD7TAJXzUj+ex6CNm78rLZRr0NRcTCqN8JTyYKDb2ZltYVaSdlYF4armFMSEKitCX+Q9M MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr3647076qar.99.1398695271052; Mon, 28 Apr 2014 07:27:51 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Mon, 28 Apr 2014 07:27:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 07:27:50 -0700 Message-ID: From: Andy Bierman To: feng.chong33@zte.com.cn Content-Type: multipart/alternative; boundary=001a11c30886c8349104f81b1e46 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AmP22CnqnyMKW5rytd8J4wO2UO4 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 14:27:55 -0000 --001a11c30886c8349104f81b1e46 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, This seems like a lot of indirection to save 1 line. The reader has to go find the exception-stmt. It does make me wonder how many developers are using error-app-tag? Do you use the values hard-wired from NETCONF and YANG? Do you use your own error-app-tag values? What do you do when an error has the standard error-app-tag instead of the vendor tag? Did you merge your classification system with the standard or do they step on each other? IMO error-app-tag extensibility is not well thought-out. It is not multi-vendor interoperable if vendors define their own values. The error-message leaf is not really intended to provide any interoperability value, so it is OK that it is vendor-specific. Andy On Mon, Apr 28, 2014 at 2:45 AM, wrote: > Hi all, > * I suggest add 'exception' statement to make 'error-app-tag' and > 'error-message' can be reused and make it possible to express multi > 'error-app-tag' or 'error-msg'.* > * 'exception' statement can be mapped to 'rpc-error'element in > NETCONF.* > exception statement's sub statement: > +---------------+-------------+ > | substatement | cardinality | > +---------------+-------------+ > | description | 0..1 | > | error-app-tag | 0..1 | > | error-message | 0..1 | > | reference | 0..1 | > +---------------+-------------+ > For example: > exception foo { > error-app-tag "abc"; > error-message "This is just a example"; > } > > and add 'throws' statement as must's substatement. > > For example : > must "a > b or a < 1500" { > throws foo; > } > > btw: 'throws' statement can be used to declare a exception may be > thrown. > > if a 'must' expression may throw multi exceptions, the example is > listed below: > > must "a > b or a < 1500" { > throws foo1; > throws foo2; > } > > If a exception statement has no error-app-tag and error-message, it > means any exception may be thrown. > > *I also suggest add 'throws' ,'error-app-tag' and 'error-message' > statements to 'rpc' statement, it can indicate which exception may be > thrown.* > > *User who execute rpc operation can be easy to handle 'rpc-error'.* > rpc's subsatatment: > +--------------+-------------+ > | substatement | cardinality | > +--------------+-------------+ > | description | 0..1 | > | grouping | 0..n | > | if-feature | 0..n | > | input | 0..1 | > | output | 0..1 | > | reference | 0..1 | > | status | 0..1 | > | typedef | 0..n | > | error-app-tag| 0..1 | > | error-message| 0..1 | > | throws | 0..n | > +--------------+-------------+ > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11c30886c8349104f81b1e46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    This seems like a lot of indirectio= n to save 1 line.
    The reader has to go find the exception-stmt.

    It does make me wonder how many developers are usin= g error-app-tag?
    Do you use the values hard-wired from NETCONF and YANG? =A0Do you use<= /div>
    your own error-app-tag values? =A0What do you do when an error ha= s the
    standard error-app-tag instead of the vendor tag? Did you m= erge your
    classification system with the standard or do they step on each other?=

    IMO error-app-tag extensibility is not well thoug= ht-out.
    It is not multi-vendor interoperable if vendors define th= eir own values.
    The error-message leaf is not really intended to provide any interoper= ability
    value, so it is OK that it is vendor-specific.
    =

    Andy


    On Mon, Apr 28, 2014 at 2:45 AM, <f= eng.chong33@zte.com.cn> wrote:
    Hi all,
    =A0 =A0 =A0 I suggest add 'exception' statement to make 'error-app-tag' and 'erro= r-message' can be reused and make it possible to express multi 'error-app-tag' or = 9;error-msg'.
    =A0 =A0 =A0 'exception' statement can be mapped to 'rpc-error'element in NETCONF.
    =A0 =A0 =A0 exception statement's sub statement:
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---------------+-------------+
    =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| description =A0 | 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| error-app-tag | 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| error-message | 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| reference =A0 =A0 | 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---------------+-------------+
    =A0 =A0 =A0 For example:
    =A0 =A0 =A0 exception =A0foo {
    =A0 =A0 =A0 =A0 =A0 =A0error-app-tag "abc";
    =A0 =A0 =A0 =A0 =A0 =A0error-message "This is just a example";
    =A0 =A0 =A0 }

    =A0 =A0 =A0 and add 'throws' statement as must's substatement.
    =A0 =A0 =A0
    =A0 =A0 =A0 For example :
    =A0 =A0 =A0 must "a > b or a < 1500" {
    =A0 =A0 =A0 =A0 =A0 =A0throws foo;
    =A0 =A0 =A0 }
    =A0 =A0 =A0
    =A0 =A0 =A0 btw: 'throws' statement can be used to declare a exception may be thrown.

    =A0 =A0 =A0 if a 'must' expression may throw multi exceptions, the example is listed below:
    =A0 =A0 =A0
    =A0 =A0 =A0 must "a > b or a < 1500" {
    =A0 =A0 =A0 =A0 =A0 =A0 throws foo1;
    =A0 =A0 =A0 =A0 =A0 =A0 throws foo2;
    =A0 =A0 =A0 }
    =A0 =A0 =A0
    =A0 =A0 =A0 If a exception statement has no error-app-tag and error-message, it means any exception may be thrown.

    I also suggest add 'throws' ,'= error-app-tag' and 'error-message' statements to 'rpc' statement, it can i= ndicate which exception may be thrown.

    User who execute rpc operation can be easy to handle 'rpc-error'.
    =A0 =A0 =A0 rpc's subsatatment:
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--------------+-------------+
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| substatement | cardinality |
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--------------+-------------+
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| description =A0| 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| grouping =A0 =A0 | 0..n =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| if-feature =A0 | 0..n =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| input =A0 =A0 =A0 =A0| 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| output =A0 =A0 =A0 | 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| reference =A0 =A0| 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| status =A0 =A0 =A0 | 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| typedef =A0 =A0 =A0| 0..n =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| error-app-tag| 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| error-message| 0..1 =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| throws =A0 =A0 =A0 | 0..n =A0 =A0 =A0 =A0|
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--------------+-------------+ 
    
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


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


    --001a11c30886c8349104f81b1e46-- From nobody Mon Apr 28 08:08: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 F01A81A0852 for ; Mon, 28 Apr 2014 08:08:17 -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_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.651] 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 Jz-2cEdhvKNR for ; Mon, 28 Apr 2014 08:08:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DF6EA1A04C5 for ; Mon, 28 Apr 2014 08:08:14 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 54E7713F6A4; Mon, 28 Apr 2014 17:08:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398697693; bh=ze98x7djrCHzi3x5bs0tMAxg2SLPZ8KjwJCkP0hbAgc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sbDOS72e62eMW0EA+m96o/ZA6CV6DmlNvCXmwm88664+1FD4oDpVtxIa+1yNSCg4d 3wqV8HnxBt0W7yksibT3SJRP0pqD3O7vVZpmhy4HoGbh/a3w989TRtd7E5hkYtxHx3 6L194KzSKdjEoo8oqoqPNolSsXgZDQjOhGYUd0Qo= 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, 28 Apr 2014 17:08:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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/XENCm0ADC1_KELsh5vrJ37SrPpA Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 15:08:18 -0000 On 28 Apr 2014, at 16:27, Andy Bierman wrote: > Hi, >=20 > This seems like a lot of indirection to save 1 line. > The reader has to go find the exception-stmt. >=20 > It does make me wonder how many developers are using error-app-tag? > Do you use the values hard-wired from NETCONF and YANG? Do you use > your own error-app-tag values? What do you do when an error has the > standard error-app-tag instead of the vendor tag? Did you merge your > classification system with the standard or do they step on each other? >=20 > IMO error-app-tag extensibility is not well thought-out. > It is not multi-vendor interoperable if vendors define their own = values. > The error-message leaf is not really intended to provide any = interoperability > value, so it is OK that it is vendor-specific. I think both error-app-tag and error-message would be much more useful = if they could be parametrized. Schematron is really great in this = respect, e.g. Duplicate leaf-list entry "". However, I can=92t think of a syntax suitable for YANG. Lada >=20 >=20 > Andy >=20 >=20 > On Mon, Apr 28, 2014 at 2:45 AM, wrote: > Hi all,=20 > I suggest add 'exception' statement to make 'error-app-tag' and = 'error-message' can be reused and make it possible to express multi = 'error-app-tag' or 'error-msg'.=20 > 'exception' statement can be mapped to 'rpc-error'element in = NETCONF.=20 > exception statement's sub statement:=20 > +---------------+-------------+=20 > | substatement | cardinality |=20 > +---------------+-------------+=20 > | description | 0..1 |=20 > | error-app-tag | 0..1 |=20 > | error-message | 0..1 |=20 > | reference | 0..1 |=20 > +---------------+-------------+=20 > For example:=20 > exception foo {=20 > error-app-tag "abc";=20 > error-message "This is just a example";=20 > }=20 >=20 > and add 'throws' statement as must's substatement.=20 > =20 > For example :=20 > must "a > b or a < 1500" {=20 > throws foo;=20 > }=20 > =20 > btw: 'throws' statement can be used to declare a exception may = be thrown.=20 >=20 > if a 'must' expression may throw multi exceptions, the example = is listed below:=20 > =20 > must "a > b or a < 1500" {=20 > throws foo1;=20 > throws foo2;=20 > }=20 > =20 > If a exception statement has no error-app-tag and error-message, = it means any exception may be thrown.=20 >=20 > I also suggest add 'throws' ,'error-app-tag' and 'error-message' = statements to 'rpc' statement, it can indicate which exception may be = thrown.=20 >=20 > User who execute rpc operation can be easy to handle 'rpc-error'.=20 > rpc's subsatatment:=20 > +--------------+-------------+=20 > | substatement | cardinality |=20 > +--------------+-------------+=20 > | description | 0..1 |=20 > | grouping | 0..n |=20 > | if-feature | 0..n |=20 > | input | 0..1 |=20 > | output | 0..1 |=20 > | reference | 0..1 |=20 > | status | 0..1 |=20 > | typedef | 0..n |=20 > | error-app-tag| 0..1 |=20 > | error-message| 0..1 |=20 > | throws | 0..n |=20 > +--------------+-------------+=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail (and any attachment transmitted herewith) is privileged and = confidential and is intended for the exclusive use of the addressee(s). = If you are not an intended recipient, any disclosure, reproduction, = distribution or other dissemination or use of the information contained = is strictly prohibited. If you have received this mail in error, please = delete it and notify us immediately. >=20 >=20 >=20 >=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 Mon Apr 28 08:26: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 9F6751A04B9 for ; Mon, 28 Apr 2014 08:26:21 -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 0CFry6t5sBTG for ; Mon, 28 Apr 2014 08:26:18 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B10E41A0A16 for ; Mon, 28 Apr 2014 08:26:18 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id k15so1563787qaq.17 for ; Mon, 28 Apr 2014 08:26:17 -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=joo+gCNzbt/m3BmSw64NF0xBDEX3gjwxJVMo/AzExM4=; b=hxPTotRWMeGTxijfyUuO0sNKeNdXSpCQ3kz7kR3w3mbU+d3EubNh6wVVi42crTmO7a 3P61tbYEYf8kI+4ubkstL7ycMml9sx9EI02hr1wi1JdSbL1MFrj/fv0kOj5StTbQpe6T mLMz2hKw+GIFGMMUt9YGbiTDn8btDo/o3CWm7WPNbdt7lBInKcP1KxY/NcmVewRQhKnh qH20mBvHWg+U6ZanXQSun9P2Tkp/P0Xffvm09YwkppLjMiLtmsG/EO+vjFfLIl0cJrJj 889Dn4Rlt4FFWdpAAgwsBZe7r9FTR+dwS/FDSNtL8m8y2xTMwd5qlDDYqnfUQ2RWiQYW 7pvQ== X-Gm-Message-State: ALoCoQmBISDGtXgX4343IyUUDhhKa4aMXBvlS2rq6MUMho6XLw6kFr0KVErYbmTVjG53wrBK2iJU MIME-Version: 1.0 X-Received: by 10.140.18.173 with SMTP id 42mr10447669qgf.94.1398698777753; Mon, 28 Apr 2014 08:26:17 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Mon, 28 Apr 2014 08:26:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 08:26:17 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11351cb2cbd33a04f81bef61 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gBfrNe4WHEmY5_Uiv95IUWNUk30 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 15:26:22 -0000 --001a11351cb2cbd33a04f81bef61 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 28, 2014 at 8:08 AM, Ladislav Lhotka wrote: > > On 28 Apr 2014, at 16:27, Andy Bierman wrote: > > > Hi, > > > > This seems like a lot of indirection to save 1 line. > > The reader has to go find the exception-stmt. > > > > It does make me wonder how many developers are using error-app-tag? > > Do you use the values hard-wired from NETCONF and YANG? Do you use > > your own error-app-tag values? What do you do when an error has the > > standard error-app-tag instead of the vendor tag? Did you merge your > > classification system with the standard or do they step on each other? > > > > IMO error-app-tag extensibility is not well thought-out. > > It is not multi-vendor interoperable if vendors define their own values. > > The error-message leaf is not really intended to provide any > interoperability > > value, so it is OK that it is vendor-specific. > > I think both error-app-tag and error-message would be much more useful if > they could be parametrized. Schematron is really great in this respect, e.g. > > Duplicate leaf-list entry "". > > However, I can't think of a syntax suitable for YANG. > > I would like to keep YANG as simple as possible. The problem with error-app-tag is that the classification system is a flat list of arbitrary strings. Yuma* has one of these arbitrary classification systems. The handful of ad-hoc standard error-app-tags will over-ride these values. You do re-raise the point of a structured error-message; e.g., sprintf w/ parameters from elsewhere in the . (Make sure this is on the issue list.) IMO, error-app-tag needs to be a leaf-list, not a leaf. That would allow multiple classification systems -- vendor + standard. (If we were really learning from the SMIng/EoS disaster, we would also be chartering YANG 1.1 + NETCONF 1.2 + RESTCONF 1.0 as a coordinated effort.) Lada > > > > > > > Andy > > > > > > On Mon, Apr 28, 2014 at 2:45 AM, wrote: > > Hi all, > > I suggest add 'exception' statement to make 'error-app-tag' and > 'error-message' can be reused and make it possible to express multi > 'error-app-tag' or 'error-msg'. > > 'exception' statement can be mapped to 'rpc-error'element in > NETCONF. > > exception statement's sub statement: > > +---------------+-------------+ > > | substatement | cardinality | > > +---------------+-------------+ > > | description | 0..1 | > > | error-app-tag | 0..1 | > > | error-message | 0..1 | > > | reference | 0..1 | > > +---------------+-------------+ > > For example: > > exception foo { > > error-app-tag "abc"; > > error-message "This is just a example"; > > } > > > > and add 'throws' statement as must's substatement. > > > > For example : > > must "a > b or a < 1500" { > > throws foo; > > } > > > > btw: 'throws' statement can be used to declare a exception may be > thrown. > > > > if a 'must' expression may throw multi exceptions, the example is > listed below: > > > > must "a > b or a < 1500" { > > throws foo1; > > throws foo2; > > } > > > > If a exception statement has no error-app-tag and error-message, > it means any exception may be thrown. > > > > I also suggest add 'throws' ,'error-app-tag' and 'error-message' > statements to 'rpc' statement, it can indicate which exception may be > thrown. > > > > User who execute rpc operation can be easy to handle 'rpc-error'. > > rpc's subsatatment: > > +--------------+-------------+ > > | substatement | cardinality | > > +--------------+-------------+ > > | description | 0..1 | > > | grouping | 0..n | > > | if-feature | 0..n | > > | input | 0..1 | > > | output | 0..1 | > > | reference | 0..1 | > > | status | 0..1 | > > | typedef | 0..n | > > | error-app-tag| 0..1 | > > | error-message| 0..1 | > > | throws | 0..n | > > +--------------+-------------+ > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this mail > (and any attachment transmitted herewith) is privileged and confidential > and is intended for the exclusive use of the addressee(s). If you are not > an intended recipient, any disclosure, reproduction, distribution or other > dissemination or use of the information contained is strictly prohibited. > If you have received this mail in error, please delete it and notify us > immediately. > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11351cb2cbd33a04f81bef61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Mon, Apr 28, 2014 at 8:08 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

    On 28 Apr 2014, at 16:27, Andy Bierman <andy@yumaworks.com> wrote:

    > Hi,
    >
    > This seems like a lot of indirection to save 1 line.
    > The reader has to go find the exception-stmt.
    >
    > It does make me wonder how many developers are using error-app-tag? > Do you use the values hard-wired from NETCONF and YANG?  Do you u= se
    > your own error-app-tag values?  What do you do when an error has = the
    > standard error-app-tag instead of the vendor tag? Did you merge your > classification system with the standard or do they step on each other?=
    >
    > IMO error-app-tag extensibility is not well thought-out.
    > It is not multi-vendor interoperable if vendors define their own value= s.
    > The error-message leaf is not really intended to provide any interoper= ability
    > value, so it is OK that it is vendor-specific.

    I think both error-app-tag and error-message would be much more useful if t= hey could be parametrized. Schematron is really great in this respect, e.g.=

       Duplicate leaf-list entry "<sch:value-of select=3D&quo= t;."/>".

    However, I can’t think of a syntax suitable for YANG.


    I would like to keep YANG as simple as= possible.

    The problem with error-app-tag is that = the classification system is
    a flat list of arbitrary strings. &n= bsp;Yuma* has one of these arbitrary classification
    systems.  The handful of ad-hoc standard error-app-tags will over= -ride these
    values.

    You do re-raise the = point of a structured error-message; e.g., sprintf w/ parameters
    = from elsewhere in the <rpc-error>.  (Make sure this is on the is= sue list.)

    IMO, error-app-tag needs to be a leaf-list, not a leaf.=
    That would allow multiple classification systems -- vendor + sta= ndard.

    (If we were really learning from the SMIng/= EoS disaster, we would also
    be chartering YANG 1.1 +  NETCONF 1.2 + RESTCONF 1.0 as a coordin= ated
    effort.)


    Lada

    >
    >
    > Andy
    >
    >
    > On Mon, Apr 28, 2014 at 2:45 AM, <feng.chong33@zte.com.cn> wrote:
    > Hi all,
    >       I suggest add 'exception' statement to ma= ke 'error-app-tag' and 'error-message' can be reused and ma= ke it possible to express multi 'error-app-tag' or 'error-msg&#= 39;.
    >       'exception' statement can be mapped to &#= 39;rpc-error'element in NETCONF.
    >       exception statement's sub statement:
    >                  +-------= --------+-------------+
    >                  | substa= tement  | cardinality |
    >                  +-------= --------+-------------+
    >                  | descri= ption   | 0..1        |
    >                  | error-= app-tag | 0..1        |
    >                  | error-= message | 0..1        |
    >                  | refere= nce     | 0..1        |
    >                  +-------= --------+-------------+
    >       For example:
    >       exception  foo {
    >            error-app-tag "abc"= ;
    >            error-message "This is j= ust a example";
    >       }
    >
    >       and add 'throws' statement as must's = substatement.
    >
    >       For example :
    >       must "a > b or a < 1500" {
    >            throws foo;
    >       }
    >
    >       btw: 'throws' statement can be used to de= clare a exception may be thrown.
    >
    >       if a 'must' expression may throw multi ex= ceptions, the example is listed below:
    >
    >       must "a > b or a < 1500" {
    >             throws foo1;
    >             throws foo2;
    >       }
    >
    >       If a exception statement has no error-app-tag and= error-message, it means any exception may be thrown.
    >
    > I also suggest add 'throws' ,'error-app-tag' and '= error-message' statements to 'rpc' statement, it can indicate w= hich exception may be thrown.
    >
    > User who execute rpc operation can be easy to handle 'rpc-error= 9;.
    >       rpc's subsatatment:
    >                  +-------= -------+-------------+
    >                  | substa= tement | cardinality |
    >                  +-------= -------+-------------+
    >                  | descri= ption  | 0..1        |
    >                  | groupi= ng     | 0..n        |
    >                  | if-fea= ture   | 0..n        |
    >                  | input =        | 0..1        |
    >                  | output=       | 0..1        |
    >                  | refere= nce    | 0..1        |
    >                  | status=       | 0..1        |
    >                  | typede= f      | 0..n        |
    >                  | error-= app-tag| 0..1        |
    >                  | error-= message| 0..1        |
    >                  | throws=       | 0..n        |
    >                  +-------= -------+-------------+
    >
    > --------------------------------------------------------
    > ZTE Information Security Notice: The information contained in this mai= l (and any attachment transmitted herewith) is privileged and confidential = and is intended for the exclusive use of the addressee(s).  If you are= not an intended recipient, any disclosure, reproduction, distribution or o= ther dissemination or use of the information contained is strictly prohibit= ed.  If you have received this mail in error, please delete it and not= ify us immediately.
    >
    >
    >
    >
    > _______________________________________________
    > netmod mailing list
    > netmod@ietf.org
    > https://www.ietf.org/mailman/listinfo/netmod
    >
    >
    > _______________________________________________
    > netmod mailing list
    > netmod@ietf.org
    > https://www.ietf.org/mailman/listinfo/netmod

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





    --001a11351cb2cbd33a04f81bef61-- From nobody Mon Apr 28 10:12: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 48B451A0312 for ; Mon, 28 Apr 2014 10:12: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 sHjLxBJkY2v3 for ; Mon, 28 Apr 2014 10:12:15 -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 958FB1A6FCD for ; Mon, 28 Apr 2014 10:12:15 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so5344586qap.37 for ; Mon, 28 Apr 2014 10:12: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:date:message-id:subject:from:to :content-type; bh=bGfdwWnzmYfsPpNgWQ6tQ3TE8Jkavo1BSKIcxLdbm/E=; b=JgY63tbM4P4jhwnn1bnZ1IzFWHSxegfpdM/II9TN2d7Zrn0BI3f/cQcfDAHXeTdy5l Cmpt1OS+y5/GBKcFDJ/Ui1MRV0frMZpFdXPHJ26uTJZXz/RktziaR2IrRe23wbvpNBK5 zErgyspLBDGTmEVf68NKr6RnPIEZbWZT3xLrTFTZEyfhenUhNRlo9hR9uiBstOiZb05e MR8aJNoSOBBa1wn0UoJ2C/3ufsG8LmX4zZ0N+IFx/ShITGfpDNBMVmsPrX91c8ASvCxf iv7kO2AJTnm4Me7VvVgVHlYliiv9IVKL6Jk/3ZF/mFxzyzX15YJWeZHgQIULOtMe2MKw sZnw== X-Gm-Message-State: ALoCoQlqJPXtr9r+tVdYjndtpW9+mvWq1R4fJg5v7buclcik77909yO7tItTstgcXpWzOLUtXBkK MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr10800231qat.78.1398705134337; Mon, 28 Apr 2014 10:12:14 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Mon, 28 Apr 2014 10:12:14 -0700 (PDT) Date: Mon, 28 Apr 2014 10:12:14 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b672b44adc11004f81d6a42 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_eogUXEMDi5_28a7NFSvpOo-XFs Subject: [netmod] YANG 1.1 Issue: YANG Conformance 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, 28 Apr 2014 17:12:18 -0000 --047d7b672b44adc11004f81d6a42 Content-Type: text/plain; charset=ISO-8859-1 Hi, The YANG conformance issues are not listed as part of the YANG 1.1 issue list. I would like the YANG Conformance draft added as a WG deliverable to provide a service-oriented conformance model that allows clients to better understand multi-module and partial module conformance requirements. The current conformance model requires that a server implement all of the base module if even 1 definition is imported from that module. Servers do not actually do that, so the current conformance model is inaccurate and insufficient for expressing the conformance relationships between YANG modules. Solution Proposal: http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-02.txt --047d7b672b44adc11004f81d6a42 Content-Type: text/html; charset=ISO-8859-1
    Hi,

    The YANG conformance issues are not listed as part of the YANG 1.1 issue list.

    I would like the YANG Conformance draft added as a WG deliverable to provide
    a service-oriented conformance model that allows clients to better understand
    multi-module and partial module conformance requirements.

    The current conformance model requires that a server implement
    all of the base module if even 1 definition is imported from that module.
    Servers do not actually do that, so the current conformance model is inaccurate
    and insufficient for expressing the conformance relationships between
    YANG modules.

    Solution Proposal:



    --047d7b672b44adc11004f81d6a42-- From nobody Mon Apr 28 11:55: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 957581A04F1 for ; Mon, 28 Apr 2014 11:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 ekH6bJnO0LPv for ; Mon, 28 Apr 2014 11:55: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 A16C81A02AC for ; Mon, 28 Apr 2014 11:55:17 -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 6DA653941CD; Mon, 28 Apr 2014 20:55:14 +0200 (CEST) Date: Mon, 28 Apr 2014 20:55:13 +0200 (CEST) Message-Id: <20140428.205513.245477594.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/MD2weR7HyOLIbVq_se6R7h6FNjs Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 18:55:19 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDI4IEFwciAy MDE0LCBhdCAxNjoyNywgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0K PiANCj4gPiBIaSwNCj4gPiANCj4gPiBUaGlzIHNlZW1zIGxpa2UgYSBsb3Qgb2YgaW5kaXJlY3Rp b24gdG8gc2F2ZSAxIGxpbmUuDQo+ID4gVGhlIHJlYWRlciBoYXMgdG8gZ28gZmluZCB0aGUgZXhj ZXB0aW9uLXN0bXQuDQo+ID4gDQo+ID4gSXQgZG9lcyBtYWtlIG1lIHdvbmRlciBob3cgbWFueSBk ZXZlbG9wZXJzIGFyZSB1c2luZyBlcnJvci1hcHAtdGFnPw0KPiA+IERvIHlvdSB1c2UgdGhlIHZh bHVlcyBoYXJkLXdpcmVkIGZyb20gTkVUQ09ORiBhbmQgWUFORz8gIERvIHlvdSB1c2UNCj4gPiB5 b3VyIG93biBlcnJvci1hcHAtdGFnIHZhbHVlcz8gIFdoYXQgZG8geW91IGRvIHdoZW4gYW4gZXJy b3IgaGFzIHRoZQ0KPiA+IHN0YW5kYXJkIGVycm9yLWFwcC10YWcgaW5zdGVhZCBvZiB0aGUgdmVu ZG9yIHRhZz8gRGlkIHlvdSBtZXJnZSB5b3VyDQo+ID4gY2xhc3NpZmljYXRpb24gc3lzdGVtIHdp dGggdGhlIHN0YW5kYXJkIG9yIGRvIHRoZXkgc3RlcCBvbiBlYWNoIG90aGVyPw0KPiA+IA0KPiA+ IElNTyBlcnJvci1hcHAtdGFnIGV4dGVuc2liaWxpdHkgaXMgbm90IHdlbGwgdGhvdWdodC1vdXQu DQo+ID4gSXQgaXMgbm90IG11bHRpLXZlbmRvciBpbnRlcm9wZXJhYmxlIGlmIHZlbmRvcnMgZGVm aW5lIHRoZWlyIG93biB2YWx1ZXMuDQo+ID4gVGhlIGVycm9yLW1lc3NhZ2UgbGVhZiBpcyBub3Qg cmVhbGx5IGludGVuZGVkIHRvIHByb3ZpZGUgYW55IGludGVyb3BlcmFiaWxpdHkNCj4gPiB2YWx1 ZSwgc28gaXQgaXMgT0sgdGhhdCBpdCBpcyB2ZW5kb3Itc3BlY2lmaWMuDQo+IA0KPiBJIHRoaW5r IGJvdGggZXJyb3ItYXBwLXRhZyBhbmQgZXJyb3ItbWVzc2FnZSB3b3VsZCBiZSBtdWNoIG1vcmUg dXNlZnVsIGlmIHRoZXkNCj4gY291bGQgYmUgcGFyYW1ldHJpemVkLg0KDQpOb3QgZXJyb3ItYXBw LXRhZy4gIEl0IGlzIHN1cHBvc2VkIHRvIGJlIGEgc3RhdGljIHRva2VuLg0KDQo+IFNjaGVtYXRy b24gaXMgcmVhbGx5IGdyZWF0IGluIHRoaXMgcmVzcGVjdCwgZS5nLg0KPiANCj4gICAgRHVwbGlj YXRlIGxlYWYtbGlzdCBlbnRyeSAiPHNjaDp2YWx1ZS1vZiBzZWxlY3Q9Ii4iLz4iLg0KPiANCj4g SG93ZXZlciwgSSBjYW7igJl0IHRoaW5rIG9mIGEgc3ludGF4IHN1aXRhYmxlIGZvciBZQU5HLg0K DQpXZSdyZSB1c2luZyBYUGF0aCBleHByZXNzaW9ucyAoZWxzZXdoZXJlKSBlbWJlZGRlZCB3aXRo aW4gY3VybHkNCmJyYWNrZXRzLiAgU29tZXRoaW5nIGxpa2UgdGhpczoNCg0KICBsaXN0IGludGVy ZmFjZSB7DQogICAga2V5IG5hbWU7DQogICAgbXVzdCAibXR1ID49IDE1MDAiIHsNCiAgICAgIGVy cm9yLW1lc3NhZ2UNCiAgICAgICAgIkludGVyZmFjZSB7bmFtZX0ncyBtdHUgaXMge210dX0sIG11 c3QgYmUgPj0gMTUwMCI7DQogICAgfQ0KICAgIC4uLg0KICAgfQ0KDQpUaGUgc3RyaW5nIHdpdGgg dGhlIGN1cmx5IGJyYWNrZXRzIGlzIGV2YWx1YXRlZCBhcyBhbiBYUGF0aCBleHByZXNzaW9uDQph bmQgY29udmVydGVkIHRvIGEgc3RyaW5nLiAgVGhpcyBzdHJpbmcgaXMgc3Vic3RpdHV0ZWQgaW5z dGVhZCBvZiB0aGUNCmN1cmx5IGJyYWNrZXQgZXhwcmVzc2lvbi4NCg0KDQovbWFydGluDQo= From nobody Mon Apr 28 12:27: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 452A71A702F for ; Mon, 28 Apr 2014 12:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 AJxqgFK75XCE for ; Mon, 28 Apr 2014 12:27:40 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B21A04F1 for ; Mon, 28 Apr 2014 12:27:40 -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 BB74937C364; Mon, 28 Apr 2014 21:27:38 +0200 (CEST) Date: Mon, 28 Apr 2014 21:27:38 +0200 (CEST) Message-Id: <20140428.212738.357299851.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: 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/-x7vKLWPJeAXkkC6rSYMHDhoyrM Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 19:27:43 -0000 Andy Bierman wrote: > IMO error-app-tag extensibility is not well thought-out. +1 I always thought it should have been a QName. And I agree it should have been a leaf-list. /martin From nobody Mon Apr 28 12:49: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 7DFBD1A6F49 for ; Mon, 28 Apr 2014 12:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 JSEw7-OuhAoC for ; Mon, 28 Apr 2014 12:49:14 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 98A611A064C for ; Mon, 28 Apr 2014 12:49:14 -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 753BD37C365; Mon, 28 Apr 2014 21:49:13 +0200 (CEST) Date: Mon, 28 Apr 2014 21:49:12 +0200 (CEST) Message-Id: <20140428.214912.529862255.mbj@tail-f.com> To: feng.chong33@zte.com.cn From: Martin Bjorklund In-Reply-To: References: 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/8ULgCZMZU0_CdczZiZftadTRt8c Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 19:49:17 -0000 Hi, Added as Y43. /martin feng.chong33@zte.com.cn wrote: > Hi all, > I suggest add 'exception' statement to make 'error-app-tag' and > 'error-message' can be reused and make it possible to express multi > 'error-app-tag' or 'error-msg'. > 'exception' statement can be mapped to 'rpc-error'element in > NETCONF. > exception statement's sub statement: > +---------------+-------------+ > | substatement | cardinality | > +---------------+-------------+ > | description | 0..1 | > | error-app-tag | 0..1 | > | error-message | 0..1 | > | reference | 0..1 | > +---------------+-------------+ > For example: > exception foo { > error-app-tag "abc"; > error-message "This is just a example"; > } > > and add 'throws' statement as must's substatement. > > For example : > must "a > b or a < 1500" { > throws foo; > } > > btw: 'throws' statement can be used to declare a exception may be > thrown. > > if a 'must' expression may throw multi exceptions, the example is > listed below: > > must "a > b or a < 1500" { > throws foo1; > throws foo2; > } > > If a exception statement has no error-app-tag and error-message, it > means any exception may be thrown. > > I also suggest add 'throws' ,'error-app-tag' and 'error-message' > statements to 'rpc' statement, it can indicate which exception may be > thrown. > > User who execute rpc operation can be easy to handle 'rpc-error'. > rpc's subsatatment: > +--------------+-------------+ > | substatement | cardinality | > +--------------+-------------+ > | description | 0..1 | > | grouping | 0..n | > | if-feature | 0..n | > | input | 0..1 | > | output | 0..1 | > | reference | 0..1 | > | status | 0..1 | > | typedef | 0..n | > | error-app-tag| 0..1 | > | error-message| 0..1 | > | throws | 0..n | > +--------------+-------------+ > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and > any attachment transmitted herewith) is privileged and confidential and is > intended for the exclusive use of the addressee(s). If you are not an intended > recipient, any disclosure, reproduction, distribution or other dissemination or > use of the information contained is strictly prohibited. If you have received > this mail in error, please delete it and notify us immediately. From nobody Mon Apr 28 12:49: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 6BAE01A6FBA for ; Mon, 28 Apr 2014 12:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 2jj5dEX6VWa2 for ; Mon, 28 Apr 2014 12:49: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 524F11A064C for ; Mon, 28 Apr 2014 12:49: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 006F237C364; Mon, 28 Apr 2014 21:49:42 +0200 (CEST) Date: Mon, 28 Apr 2014 21:49:42 +0200 (CEST) Message-Id: <20140428.214942.289493603.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: 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/h_SUBZM1jL97eSmYuGgglDHksn4 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 19:49:45 -0000 Andy Bierman wrote: > You do re-raise the point of a structured error-message; e.g., sprintf w/ > parameters > from elsewhere in the . (Make sure this is on the issue list.) Added as Y44. /martin From nobody Mon Apr 28 12:51: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 C58501A6FB7 for ; Mon, 28 Apr 2014 12:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 ZT-lfvQbKBIQ for ; Mon, 28 Apr 2014 12:51:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 802A01A6FBB for ; Mon, 28 Apr 2014 12:51:11 -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 5B34037C364; Mon, 28 Apr 2014 21:51:10 +0200 (CEST) Date: Mon, 28 Apr 2014 21:51:09 +0200 (CEST) Message-Id: <20140428.215109.381969885.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: 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/HowmUQ_cw28lFg5mmaxDAsJMqjg Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Issue: YANG Conformance 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, 28 Apr 2014 19:51:26 -0000 Andy, I don't understand if you want anything added to the issues list or not. Also see Y15 and Y16; they are related. /martin Andy Bierman wrote: > Hi, > > The YANG conformance issues are not listed as part of the YANG 1.1 issue > list. > > I would like the YANG Conformance draft added as a WG deliverable to provide > a service-oriented conformance model that allows clients to better > understand > multi-module and partial module conformance requirements. > > The current conformance model requires that a server implement > all of the base module if even 1 definition is imported from that module. > Servers do not actually do that, so the current conformance model is > inaccurate > and insufficient for expressing the conformance relationships between > YANG modules. > > Solution Proposal: > > http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-02.txt From nobody Mon Apr 28 13:00: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 46F8D1A6F54 for ; Mon, 28 Apr 2014 13:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 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.651] 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 ElYR9KZE56DW for ; Mon, 28 Apr 2014 13:00:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6955C1A03FC for ; Mon, 28 Apr 2014 13:00:37 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 23D8E13F686; Mon, 28 Apr 2014 22:00:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398715236; bh=RXwcMF74VFQ8i49eKFNySPpSqbgbtj8ZfdQ9A2aKUiU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UkkotHa6mABOT+Us9HmmthOzf+nZMZqG0ZOXcOoNp3+DH9sDYIuu0OXajrEl/1s0T 1GQVTmKwHFwbJdw1w+nruWmdrYn2/5WG3uXoM3ygtNxiTfIfhFkjzKcGhwuL4ktED5 IJiEL1kc7rKzLhQPDW3Qn0/Q+j5hC55KVnlkmBLU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140428.205513.245477594.mbj@tail-f.com> Date: Mon, 28 Apr 2014 22:00:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72FEE338-13BE-4FF8-AC86-CDF7EA94F8E6@nic.cz> References: <20140428.205513.245477594.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/T8Ive3CRZ_Yai5EqNv0FGkCb-W8 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 20:00:40 -0000 On 28 Apr 2014, at 20:55, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 28 Apr 2014, at 16:27, Andy Bierman wrote: >>=20 >>> Hi, >>>=20 >>> This seems like a lot of indirection to save 1 line. >>> The reader has to go find the exception-stmt. >>>=20 >>> It does make me wonder how many developers are using error-app-tag? >>> Do you use the values hard-wired from NETCONF and YANG? Do you use >>> your own error-app-tag values? What do you do when an error has the >>> standard error-app-tag instead of the vendor tag? Did you merge your >>> classification system with the standard or do they step on each = other? >>>=20 >>> IMO error-app-tag extensibility is not well thought-out. >>> It is not multi-vendor interoperable if vendors define their own = values. >>> The error-message leaf is not really intended to provide any = interoperability >>> value, so it is OK that it is vendor-specific. >>=20 >> I think both error-app-tag and error-message would be much more = useful if they >> could be parametrized. >=20 > Not error-app-tag. It is supposed to be a static token. >=20 >> Schematron is really great in this respect, e.g. >>=20 >> Duplicate leaf-list entry "". >>=20 >> However, I can=92t think of a syntax suitable for YANG. >=20 > We're using XPath expressions (elsewhere) embedded within curly > brackets. Something like this: >=20 > list interface { > key name; > must "mtu >=3D 1500" { > error-message > "Interface {name}'s mtu is {mtu}, must be >=3D 1500"; > } > ... > } >=20 > The string with the curly brackets is evaluated as an XPath expression > and converted to a string. This string is substituted instead of the > curly bracket expression. IMO this is worth considering, shall we make it an issue? Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 28 13:03: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 1EDE31A6FA8 for ; Mon, 28 Apr 2014 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 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.651] 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 y0jxWNhpvSfn for ; Mon, 28 Apr 2014 13:03:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 463CB1A03FC for ; Mon, 28 Apr 2014 13:03:38 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0246713F686; Mon, 28 Apr 2014 22:03:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398715417; bh=r76LwUNT5kjBwjk3WLop8W3OQFboRdoAzpMiCqofklM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vbkBG7lVAjTWTb1rX4Fnx2FH6L5jDA/xlss7icTYsZgUIs59Vqg0FKo9ltN/WgxqB FISF5TGNYlNFJxkNIg2a0GMhEJR80fNw1ST2YkjF8r9VyjoTbAQDhMzBO08C1eV8Qr x4+e5FJH1qRAkncYppssJ/lGw+PbzD40M2e78ia8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140428.212738.357299851.mbj@tail-f.com> Date: Mon, 28 Apr 2014 22:03:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: <06FBE033-0097-4DAE-8DD4-FE97F9D06ED9@nic.cz> References: <20140428.212738.357299851.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/0fiyxsMo_KjeJf74mGvDOZINmHQ Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Mon, 28 Apr 2014 20:03:39 -0000 On 28 Apr 2014, at 21:27, Martin Bjorklund wrote: > Andy Bierman wrote: >> IMO error-app-tag extensibility is not well thought-out. > > +1 > > I always thought it should have been a QName. Perhaps an identity, similar to the exception classes in Python? Lada > > And I agree it should have been a leaf-list. > > > /martin > > _______________________________________________ > 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 28 13:38: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 1B5E61A6FEE for ; Mon, 28 Apr 2014 13:38:01 -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 KwlC8AnmotB9 for ; Mon, 28 Apr 2014 13:37:59 -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 A59DC1A6FB9 for ; Mon, 28 Apr 2014 13:37:59 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id i50so7629860qgf.15 for ; Mon, 28 Apr 2014 13:37:58 -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=5jMz7e5MDV0w8btewRe55mTRHpb496KFPL2uBOSfaiY=; b=afHF0jAgR2ASdSVZHc7AOgFMNFubuGuryX/EyyXG89S3WnfCXvY/24/9dj15FPDJ/d psixVdDz/Tuyl2oPkOshI+pivv+7EU2oO6MoCU6Ttbet348Ot6/egvrkT2jaaV1pi9AN fNjGizGYumnWa+LyYuzHUHxaC60ywOOIcJxp5ubD2IHdQ1cyi/Syo8PIUMt6MlhaeqG0 6XWXVp3AKIHOLcKnHJpYbfB9K+FY5kHeyPaRSgyzrAvqHj1ANz7nx3juGNrzdX3G1HgU ma+cxHk8tTu1jC/e8NkkNdks+FoZfScm8ofteorER696fzujSdX7oKA/Ri30uIQuYXGt WR0g== X-Gm-Message-State: ALoCoQn8gGmXak4nsFUhWi4y/bJBdfGeE8xMgN3IG0DEBzQWd9JeUF3IFSeXYUu+2DD2z5c2WTyV MIME-Version: 1.0 X-Received: by 10.140.27.212 with SMTP id 78mr34307682qgx.18.1398717478660; Mon, 28 Apr 2014 13:37:58 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Mon, 28 Apr 2014 13:37:58 -0700 (PDT) In-Reply-To: <20140428.215109.381969885.mbj@tail-f.com> References: <20140428.215109.381969885.mbj@tail-f.com> Date: Mon, 28 Apr 2014 13:37:58 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c14d66751c8d04f8204aa9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kKcWuWM-xSFANkrUGeGNYQOMwZw Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Issue: YANG Conformance 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, 28 Apr 2014 20:38:01 -0000 --001a11c14d66751c8d04f8204aa9 Content-Type: text/plain; charset=ISO-8859-1 Hi, Perhaps you should read my email more carefully. There are 4 problems: 1) service conformance cannot be specified, because it may require multiple YANG modules, or portions of specific modules 2) conformance requirements for new (perhaps external) use-cases are not supported, because new if-feature statements cannot be added or changed. A use case may require implementation of a mandatory=false object, which is not supported in YANG. 3) A server often does not implement an entire imported module if it just needs part of it (e.g. an identity, typedef, ot notification). The YANG conformance tells the client that the entire base module is supported 4) advertisement of service-level conformance is not supported Are you objecting to adopting the YANG Conformance draft as a WG draft? Andy On Mon, Apr 28, 2014 at 12:51 PM, Martin Bjorklund wrote: > Andy, > > I don't understand if you want anything added to the issues list or > not. > > Also see Y15 and Y16; they are related. > > > /martin > > > > Andy Bierman wrote: > > Hi, > > > > The YANG conformance issues are not listed as part of the YANG 1.1 issue > > list. > > > > I would like the YANG Conformance draft added as a WG deliverable to > provide > > a service-oriented conformance model that allows clients to better > > understand > > multi-module and partial module conformance requirements. > > > > The current conformance model requires that a server implement > > all of the base module if even 1 definition is imported from that module. > > Servers do not actually do that, so the current conformance model is > > inaccurate > > and insufficient for expressing the conformance relationships between > > YANG modules. > > > > Solution Proposal: > > > > http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-02.txt > --001a11c14d66751c8d04f8204aa9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    Perhaps you should read my email mo= re carefully.
    There are 4 problems:

    =A0 = 1) service conformance cannot be specified,
    =A0 =A0 =A0 because i= t may require multiple YANG modules, or portions
    =A0 =A0 =A0 of specific modules

    =A0 2) confor= mance requirements for new (perhaps external) use-cases
    =A0 =A0 = =A0are not supported, because new if-feature statements cannot be
    =A0 =A0 =A0added or changed. A use case may require implementation of
    =A0 =A0 =A0a mandatory=3Dfalse object, which is not supported in YANG.=

    =A0 3) A server often does not implement an entir= e imported module if it just
    =A0 =A0 =A0 needs part of it (e.g. a= n identity, typedef, ot notification). =A0The YANG
    =A0 =A0 =A0 conformance tells the client that the entire base module i= s supported

    =A0 4) advertisement of service-level = conformance is not supported

    Are you objecting to = adopting the YANG Conformance draft as a WG draft?


    Andy


    =


    On Mon,= Apr 28, 2014 at 12:51 PM, Martin Bjorklund <mbj@tail-f.com> = wrote:
    Andy,

    I don't understand if you want anything added to the issues list or
    not.

    Also see Y15 and Y16; they are related.


    /martin



    Andy Bierman <andy@yumaworks.com> wrote:
    > Hi,
    >
    > The YANG conformance issues are not listed as part of the YANG 1.1 iss= ue
    > list.
    >
    > I would like the YANG Conformance draft added as a WG deliverable to p= rovide
    > a service-oriented conformance model that allows clients to better
    > understand
    > multi-module and partial module conformance requirements.
    >
    > The current conformance model requires that a server implement
    > all of the base module if even 1 definition is imported from that modu= le.
    > Servers do not actually do that, so the current conformance model is > inaccurate
    > and insufficient for expressing the conformance relationships between<= br> > YANG modules.
    >
    > Solution Proposal:
    >
    >     http://www.ietf.org/id/draft-bierman-netmod-yan= g-conformance-02.txt

    --001a11c14d66751c8d04f8204aa9-- From nobody Tue Apr 29 00:17: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 C6FCE1A8890; Tue, 29 Apr 2014 00:17:44 -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 usOqRfaniuXG; Tue, 29 Apr 2014 00:17:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4F1A0317; Tue, 29 Apr 2014 00:17:43 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 00:17:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fbDkWww7aruee51FIoGECqLCOZ0 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.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, 29 Apr 2014 07:17:45 -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-15.txt Pages : 40 Date : 2014-04-29 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-15 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 29 04:06: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 221651A0833 for ; Tue, 29 Apr 2014 04:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 PIdRtFIYjxJh for ; Tue, 29 Apr 2014 04:06: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 61E321A083B for ; Tue, 29 Apr 2014 04:06:00 -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 BE6CF3B41E2; Tue, 29 Apr 2014 13:05:58 +0200 (CEST) Date: Tue, 29 Apr 2014 13:05:58 +0200 (CEST) Message-Id: <20140429.130558.378367972277895820.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <72FEE338-13BE-4FF8-AC86-CDF7EA94F8E6@nic.cz> References: <20140428.205513.245477594.mbj@tail-f.com> <72FEE338-13BE-4FF8-AC86-CDF7EA94F8E6@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/5Pf2AKGckKKatugN-l4T1X12Pc0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 new issue: add exception 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: Tue, 29 Apr 2014 11:06:02 -0000 Ladislav Lhotka wrote: > > We're using XPath expressions (elsewhere) embedded within curly > > brackets. Something like this: > > > > list interface { > > key name; > > must "mtu >= 1500" { > > error-message > > "Interface {name}'s mtu is {mtu}, must be >= 1500"; > > } > > ... > > } > > > > The string with the curly brackets is evaluated as an XPath expression > > and converted to a string. This string is substituted instead of the > > curly bracket expression. > > IMO this is worth considering, shall we make it an issue? I thought I did, turned out I forgot to checkin. Now done. Y44. /martin From nobody Tue Apr 29 04:11: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 266C51A0821 for ; Tue, 29 Apr 2014 04:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 g3H9qF1wcUAL for ; Tue, 29 Apr 2014 04:11: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 EC15C1A0858 for ; Tue, 29 Apr 2014 04:11:32 -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 6F1D73B41E2; Tue, 29 Apr 2014 13:11:31 +0200 (CEST) Date: Tue, 29 Apr 2014 13:11:31 +0200 (CEST) Message-Id: <20140429.131131.637730590299005412.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140428.215109.381969885.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/JsLak-pFvAoHMFrITAhB-Rj6veo Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Issue: YANG Conformance 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, 29 Apr 2014 11:11:36 -0000 Andy Bierman wrote: > Hi, > > Perhaps you should read my email more carefully. > There are 4 problems: > > 1) service conformance cannot be specified, > because it may require multiple YANG modules, or portions > of specific modules > > 2) conformance requirements for new (perhaps external) use-cases > are not supported, because new if-feature statements cannot be > added or changed. A use case may require implementation of > a mandatory=false object, which is not supported in YANG. > > 3) A server often does not implement an entire imported module if it just > needs part of it (e.g. an identity, typedef, ot notification). The > YANG > conformance tells the client that the entire base module is supported > > 4) advertisement of service-level conformance is not supported > > Are you objecting to adopting the YANG Conformance draft as a WG draft? First of all, I think some issues you have in this draft are handled by some of the 1.1 issues, e.g., boolean if-feature expressions. Second, it don't think this document in its current form solves the problems you mention, since it doesn't change the conformance requirements of YANG. A server still must follow the rules of 6020 (or 6020bis) even if your draft is implemented. I am all for a modular approach; if we agree on a solution with packages, 6021bis could refer to the other document. Anyway, I have added a rather generic issue Y45. /martin From nobody Tue Apr 29 05:19: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 4EC971A078B for ; Tue, 29 Apr 2014 05:19: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 9vc1ke9HwlQF for ; Tue, 29 Apr 2014 05:19:36 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC91A06D7 for ; Tue, 29 Apr 2014 05:19:35 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ih12so97122qab.38 for ; Tue, 29 Apr 2014 05:19:34 -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=i4gNN+aFGE8z5ktuUDn/TSr10LqeAMfNxkLi//MXKqI=; b=B7iubfIWTo5xAaKYove+Iq/VY3YFKQLvvVFrXYXtQFaUEd4csdo8HGZW11KbGkbFHH cyZixQvFO93sylG/3RAWv5+vBkJ9p8JQkexC768z+so4dXNu3ofIqJd+nh6ZJkC+iuFe heAQ4k6SWVKCM92qoBcrlurdfnnmHY2Ta76XshpDdaY8a/pKQW7cAOmEAwRVFtM2nd21 a3DYZ6kPaxpN+Ob+kJYldKxgYJ3jjWnxbwxs72pt5CWhaRE4ynXEVpktvvDPYK69U0fw jP8sPkqf1PhdWnlA+apzxzkKsIjeB2vybUA6BBTFYztNe3Yz/BbyvnfrdH3HfG8ZOKfP nyKA== X-Gm-Message-State: ALoCoQmqxclAkiYX98MYx3UEZGZ0gs4Vs8XqBeiuDWgI3LLL3Bj4awPjhz7UYoG7gVqojAo7beYk MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr11515803qar.99.1398773974486; Tue, 29 Apr 2014 05:19:34 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Tue, 29 Apr 2014 05:19:34 -0700 (PDT) In-Reply-To: <20140429.131131.637730590299005412.mbj@tail-f.com> References: <20140428.215109.381969885.mbj@tail-f.com> <20140429.131131.637730590299005412.mbj@tail-f.com> Date: Tue, 29 Apr 2014 05:19:34 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c30886dee43c04f82d7128 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fgCkgwHiIYp__iKAfehtLHfaFj0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Issue: YANG Conformance 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, 29 Apr 2014 12:19:39 -0000 --001a11c30886dee43c04f82d7128 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 29, 2014 at 4:11 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > Perhaps you should read my email more carefully. > > There are 4 problems: > > > > 1) service conformance cannot be specified, > > because it may require multiple YANG modules, or portions > > of specific modules > > > > 2) conformance requirements for new (perhaps external) use-cases > > are not supported, because new if-feature statements cannot be > > added or changed. A use case may require implementation of > > a mandatory=false object, which is not supported in YANG. > > > > 3) A server often does not implement an entire imported module if it > just > > needs part of it (e.g. an identity, typedef, ot notification). The > > YANG > > conformance tells the client that the entire base module is > supported > > > > 4) advertisement of service-level conformance is not supported > > > > Are you objecting to adopting the YANG Conformance draft as a WG draft? > > First of all, I think some issues you have in this draft are handled > by some of the 1.1 issues, e.g., boolean if-feature expressions. > > not really, since the original module has to be modified to change if-feature-stmts, and it is illegal to add or change if-feature-stmts. There is no way to indicate that for condition X, YANG feature Y MUST be supported. A set of purely optional features is not the same as service-level conformance. SMIv2 is far better than YANG wrt/ conformance specification. > Second, it don't think this document in its current form solves the > problems you mention, since it doesn't change the conformance > requirements of YANG. A server still must follow the rules of 6020 > (or 6020bis) even if your draft is implemented. > > yes it does. You cannot build a routing service given any single standard YANG module. You need interfaces + routing-cfg + ipv4 | ipv6. YANG has no way to specify that conformance. I am all for a modular approach; if we agree on a solution with > packages, 6021bis could refer to the other document. > > Anyway, I have added a rather generic issue Y45. > > > /martin > Andy --001a11c30886dee43c04f82d7128 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 29, 2014 at 4:11 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    Andy Bierman <andy@yumaworks.com> wrote:
    > Hi,
    >
    > Perhaps you should read my email more carefully.
    > There are 4 problems:
    >
    > =A0 1) service conformance cannot be specified,
    > =A0 =A0 =A0 because it may require multiple YANG modules, or portions<= br> > =A0 =A0 =A0 of specific modules
    >
    > =A0 2) conformance requirements for new (perhaps external) use-cases > =A0 =A0 =A0are not supported, because new if-feature statements cannot= be
    > =A0 =A0 =A0added or changed. A use case may require implementation of<= br> > =A0 =A0 =A0a mandatory=3Dfalse object, which is not supported in YANG.=
    >
    > =A0 3) A server often does not implement an entire imported module if = it just
    > =A0 =A0 =A0 needs part of it (e.g. an identity, typedef, ot notificati= on). =A0The
    > YANG
    > =A0 =A0 =A0 conformance tells the client that the entire base module i= s supported
    >
    > =A0 4) advertisement of service-level conformance is not supported
    >
    > Are you objecting to adopting the YANG Conformance draft as a WG draft= ?

    First of all, I think some issues you have in this draft are handled
    by some of the 1.1 issues, e.g., boolean if-feature expressions.


    not really, since the original module = has to be modified to change if-feature-stmts,
    and it is illegal = to add or change if-feature-stmts. =A0There is no way to indicate
    that for condition X, YANG feature Y MUST be supported. =A0A set of purely<= /div>
    optional features is not the same as service-level conformance.
    SMIv2 is far better than YANG wrt/ conformance specification.


    =A0
    Second, it don't think this document in its current form solves the
    problems you mention, since it doesn't change the conformance
    requirements of YANG. =A0A server still must follow the rules of 6020
    (or 6020bis) even if your draft is implemented.


    yes it does. =A0You cannot build a rou= ting service given any single standard
    YANG module. You need inte= rfaces + routing-cfg + ipv4 | ipv6.
    YANG has no way to specify th= at conformance.


    I am all for a modular approach; if we agree on a solution with
    packages, 6021bis could refer to the other document.

    Anyway, I have added a rather generic issue Y45.

    =A0


    /martin

    Andy<= /div>

    --001a11c30886dee43c04f82d7128-- From nobody Tue Apr 29 07:10: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 56C1B1A090D; Tue, 29 Apr 2014 07:10:05 -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 W74721_c71ZX; Tue, 29 Apr 2014 07:10:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5B31A08F0; Tue, 29 Apr 2014 07:10:03 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140429141003.22969.2351.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 07:10:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/K9n_mFOYMR2kaQ_r7IpLMWtKPjU Cc: netmod@ietf.org Subject: [netmod] Last Call: (A YANG Data Model for System Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 14:10:05 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'A YANG Data Model for System Management' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ballot/ No IPR declarations have been submitted directly on this I-D. Note that RFC 1321 and RFC 6151 are normative references to Informational documents. From nobody Tue Apr 29 10:54:01 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 594711A094A for ; Tue, 29 Apr 2014 10:53:59 -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 SHc8-yKCG56R for ; Tue, 29 Apr 2014 10:53:58 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 14CF31A0956 for ; Tue, 29 Apr 2014 10:53:58 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j107so631921qga.0 for ; Tue, 29 Apr 2014 10:53:56 -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=WjPoeWXv3TW8Bvwwd1m+icnu3r0aHE0UXdDUjJvuYYg=; b=YreiNWbU9gJ2Ub3iDxK2scAluOL7XN388cuOzax8ohEQ8/Osbp303mU0Z1sOTLUNNS ggLVJsdzhy3kdQeHyH6S5LafScA9zo19wOKs7dl2HCPe9ouuGUmoLEzk6JBAMiAGZ8gj Z396OSsfoGYR8YEPCmNtCM3ccEH+3IK74U+L3JIWohjAgmI8LxrxLjYP87o6wrPPqUR0 xXQpL232Ce8pLXIP8rMx9YkXBKaiM1ZhjEf3DjFey9BAtkzG9oi7ctJy5/NlE2QkNzDq s7Oh4xqupHXWiNVgvlmfvvdWkQoV9PAR2TNAy7hg7zhTK/ZOvKbxq3HVOLtXpHglN9lc YPRw== X-Gm-Message-State: ALoCoQnqoJoDAgmOHcfL9vzXuu4PxOasHa4g1u2HuB3wh/mLl7UHHxqaQYar9kiYlYosOWKbEfBj MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr43974416qaa.7.1398794036553; Tue, 29 Apr 2014 10:53:56 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Tue, 29 Apr 2014 10:53:56 -0700 (PDT) Date: Tue, 29 Apr 2014 10:53:56 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bea3986a9e48b04f8321dba Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VtQdNPRhf3iZx7Zz5HTvAm-D7wk Subject: [netmod] YANG 1.1 issue: data-specific attributes 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, 29 Apr 2014 17:53:59 -0000 --047d7bea3986a9e48b04f8321dba Content-Type: text/plain; charset=ISO-8859-1 Hi, There is a need to support meta-data for data returned by a NETCONF or RESTCONF server. YANG only supports attributes with hacks like the operation in ietf-netconf.yang: http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 The most common attribute (that applies to a subset of all data definitions) is the "xml:lang" attribute used in the error-message field. error-message: Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an "xml:lang" attribute as defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. We implement attributes in YANG with yet another YANG extension called 'metadata'. It is used in the 'LangString' typedef to model correctly. http://www.netconfcentral.org/modules/yuma-netconf/2013-07-07#LangString.215 The use of YANG extensions is problematic because they are completely optional and outside the language (even the hack in RFC 6241). A normative solution is needed. Proposed Solution: * A general mechanism is needed to declare data-specific and typedef-specific metadata Andy --047d7bea3986a9e48b04f8321dba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    There is a need to support meta-dat= a for data returned by a NETCONF
    or RESTCONF server. =A0YANG only= supports attributes with hacks
    like the <get> operation in= ietf-netconf.yang:


    The most common attribute (that applies to a subs= et of all data definitions)
    is the "xml:lang" attribute= used in the error-message field.

          error-message:  Contains a string suitable for human display that
      describes the error condition.  This element will not be present
      if no appropriate message is provided for a particular error
      condition.  This element SHOULD include an "xml:lang" attri=
bute as
      defined in [W3C.REC-xml-20001006] and discussed in [RFC3470].
    We implement attributes in YANG with yet another YANG extension called &#= 39;metadata'.
    It is used in the 'LangString' typedef to mode= l <error-message> correctly.

    http://www.netconfcentral.org/modules/yuma-netconf/2013-0= 7-07#LangString.215

    The use of YANG extensions is problematic be= cause they are completely optional
    and outside the language (even the <get> hack in RFC 6241). =A0A= normative solution
    is needed.


    Propo= sed Solution:

    =A0 * A general mechanism is needed to declare data-sp= ecific and typedef-specific=A0metadata


    Andy

    --047d7bea3986a9e48b04f8321dba-- From nobody Tue Apr 29 11:24: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 0B7251A0962 for ; Tue, 29 Apr 2014 11:24:29 -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_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.651] 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 vdO09E4oDVZF for ; Tue, 29 Apr 2014 11:24:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27B1A095D for ; Tue, 29 Apr 2014 11:24:27 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C7F041405A4; Tue, 29 Apr 2014 20:24:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398795866; bh=4uuIIr76N+F+V5Hfb51vmD4EiWwq1kWNjTZGuBYYCt4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=H/Cm0yp9VPG4IHsMioegXu5OWXgLRLwp2BgjZ5MOZ5IDTWoTo/4tUqW76xJCXn7+l +Bo1wXBJ0+p2bNeKQh7KaWVK9pmn4MW45X5WhOTx8V28RH/qe+Sgn9hXr4oyD1PDsE HxEWXhy0rPF+uuRk89tCPGYPQ0JP0u0Xav0V8Di8= 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: Date: Tue, 29 Apr 2014 20:24:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48141263-A153-403B-8E96-146A245E2F65@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/2HMFTGBgW4dFH0ax4tLSDpd2NtA Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 29 Apr 2014 18:24:29 -0000 On 29 Apr 2014, at 19:53, Andy Bierman wrote: > Hi, >=20 > There is a need to support meta-data for data returned by a NETCONF > or RESTCONF server. YANG only supports attributes with hacks > like the operation in ietf-netconf.yang: >=20 > = http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-e= lement-attributes.56 >=20 > The most common attribute (that applies to a subset of all data = definitions) > is the "xml:lang" attribute used in the error-message field. >=20 > error-message: Contains a string suitable for human display = that > describes the error condition. This element will not be present > if no appropriate message is provided for a particular error > condition. This element SHOULD include an "xml:lang" attribute = as > defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. >=20 >=20 > We implement attributes in YANG with yet another YANG extension called = 'metadata'. > It is used in the 'LangString' typedef to model = correctly. >=20 > = http://www.netconfcentral.org/modules/yuma-netconf/2013-07-07#LangString.2= 15 >=20 > The use of YANG extensions is problematic because they are completely = optional > and outside the language (even the hack in RFC 6241). A = normative solution > is needed. >=20 >=20 > Proposed Solution: >=20 > * A general mechanism is needed to declare data-specific and = typedef-specific metadata Is it something else than Y33? Lada >=20 >=20 > Andy >=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 29 11:36:01 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 EF3841A0974 for ; Tue, 29 Apr 2014 11:35:58 -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_34=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 fw--jd8IlVE1 for ; Tue, 29 Apr 2014 11:35:57 -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 9D7351A096B for ; Tue, 29 Apr 2014 11:35:57 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id e89so694607qgf.34 for ; Tue, 29 Apr 2014 11:35:56 -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=MPf/e11GwEiwXTyPvXAQN2yC4vMIBVoF+HpAtsHXT74=; b=UMaIxs1YN3zqkfAMs7ZsMpvqZ6tnfIERlivAYErPV2B5/vYJm7OrUvVwGbTsHicZrE J2C0oQ2rteaTj1EtBdDGTGjase9lH37rSUerxnnlqGg9ML8AJVqGjmj0y6Ttmj9JYm2u kFHoY3CBgxeXlnLvtq+RniuLH3DcpQ3NwCksYboG5PAuBuy0O1Htp/pWRQU/SZ/gXaN9 Nir4p/HENpGnWRPvgEn01736sA9ZRnHYgQjd+ZwW7L61VE8PLoY0QsDHn1KHH4qu9ktd eBORHGi32p6xeXZ8PKpUmlju+IdMdb7rS+1Hm4jqopJ0umRHryP6cw2WIb+7PRb1AQ7U oc4Q== X-Gm-Message-State: ALoCoQlfnzSZLtW4Oe49D+2iGTtIDBuJyNl3XqyV13xbAmnbXaFBuYlQ38zVts86Z9oUcZIR8v+3 MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr20081612qat.78.1398796556250; Tue, 29 Apr 2014 11:35:56 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Tue, 29 Apr 2014 11:35:56 -0700 (PDT) In-Reply-To: <48141263-A153-403B-8E96-146A245E2F65@nic.cz> References: <48141263-A153-403B-8E96-146A245E2F65@nic.cz> Date: Tue, 29 Apr 2014 11:35:56 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b672b44d983f904f832b335 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7chYlhJpBpjNaUPjeW0vRoBUel8 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 29 Apr 2014 18:35:59 -0000 --047d7b672b44d983f904f832b335 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 29, 2014 at 11:24 AM, Ladislav Lhotka wrote: > > On 29 Apr 2014, at 19:53, Andy Bierman wrote: > > > Hi, > > > > There is a need to support meta-data for data returned by a NETCONF > > or RESTCONF server. YANG only supports attributes with hacks > > like the operation in ietf-netconf.yang: > > > > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > > > > The most common attribute (that applies to a subset of all data > definitions) > > is the "xml:lang" attribute used in the error-message field. > > > > error-message: Contains a string suitable for human display that > > describes the error condition. This element will not be present > > if no appropriate message is provided for a particular error > > condition. This element SHOULD include an "xml:lang" attribute as > > defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. > > > > > > We implement attributes in YANG with yet another YANG extension called > 'metadata'. > > It is used in the 'LangString' typedef to model > correctly. > > > > > http://www.netconfcentral.org/modules/yuma-netconf/2013-07-07#LangString.215 > > > > The use of YANG extensions is problematic because they are completely > optional > > and outside the language (even the hack in RFC 6241). A normative > solution > > is needed. > > > > > > Proposed Solution: > > > > * A general mechanism is needed to declare data-specific and > typedef-specific metadata > > Is it something else than Y33? > > Yes -- as it says -- this is data-specific meta-data. Note this text from issue Y33: 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. How does the client know which leafs use the xml:lang attribute? Which leafs have mandatory xml:lang attributes and which ones are optional? A top-level statement might be part of the solution for this problem. I am just identifying the problem. > Lada > > Andy > > > > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b672b44d983f904f832b335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 29, 2014 at 11:24 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

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

    > Hi,
    >
    > There is a need to support meta-data for data returned by a NETCONF > or RESTCONF server. =A0YANG only supports attributes with hacks
    > like the <get> operation in ietf-netconf.yang:
    >
    > http://www.netconfce= ntral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56<= /a>
    >
    > The most common attribute (that applies to a subset of all data defini= tions)
    > is the "xml:lang" attribute used in the error-message field.=
    >
    > =A0 =A0 =A0 error-message: =A0Contains a string suitable for human dis= play that
    > =A0 =A0 =A0 describes the error condition. =A0This element will not be= present
    > =A0 =A0 =A0 if no appropriate message is provided for a particular err= or
    > =A0 =A0 =A0 condition. =A0This element SHOULD include an "xml:lan= g" attribute as
    > =A0 =A0 =A0 defined in [W3C.REC-xml-20001006] and discussed in [RFC347= 0].
    >
    >
    > We implement attributes in YANG with yet another YANG extension called= 'metadata'.
    > It is used in the 'LangString' typedef to model <error-mess= age> correctly.
    >
    >     http://www.netconfcentral.org/modules/= yuma-netconf/2013-07-07#LangString.215
    >
    > The use of YANG extensions is problematic because they are completely = optional
    > and outside the language (even the <get> hack in RFC 6241). =A0A= normative solution
    > is needed.
    >
    >
    > Proposed Solution:
    >
    > =A0 * A general mechanism is needed to declare data-specific and typed= ef-specific metadata

    Is it something else than Y33?


    Yes -- as it says -- this is data-spec= ific meta-data.
    Note this text from issue Y33:

      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.
    How does the client know which leafs use the xml:lang attribute?=
    Which leafs have mandatory xml:lang attributes and which ones ar= e optional?

    A top-level statement might be part of= the solution for this problem.
    I am just identifying the problem.


    =
    =A0
    Lada



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

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





    --047d7b672b44d983f904f832b335-- From nobody Tue Apr 29 11:52: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 41F821A0957 for ; Tue, 29 Apr 2014 11:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, RP_MATCHES_RCVD=-0.651] 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 tv4ia2Euiskz for ; Tue, 29 Apr 2014 11:52:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CAFE91A0955 for ; Tue, 29 Apr 2014 11:52:29 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 634861400FD; Tue, 29 Apr 2014 20:52:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398797547; bh=rvVDNtOYGF9AN+3KlBomnBpywYtwDEsMgpIIqrBQFBM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Vd/mxZqbQq80kIRNq5CZEJ8VP+ZK3zvLIYw6yMXYwmMpdHsbeRL5zANXZYH8dD08y lihDeIxdIKRxbhZhvvGblH4rUlYxh8lz3ssW4i6K0PVJm7Fr6TqMn4WznDYPuHJIaD XBo8nQlsCS/iDIxZHanoRumTlPpreGANO/Cwv88Y= 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: Date: Tue, 29 Apr 2014 20:52:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> References: <48141263-A153-403B-8E96-146A245E2F65@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/5FVE-ffpo6LtI1q5mgoge9mUJtk Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 29 Apr 2014 18:52:31 -0000 On 29 Apr 2014, at 20:35, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Apr 29, 2014 at 11:24 AM, Ladislav Lhotka = wrote: >=20 > On 29 Apr 2014, at 19:53, Andy Bierman wrote: >=20 > > Hi, > > > > There is a need to support meta-data for data returned by a NETCONF > > or RESTCONF server. YANG only supports attributes with hacks > > like the operation in ietf-netconf.yang: > > > > = http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-e= lement-attributes.56 > > > > The most common attribute (that applies to a subset of all data = definitions) > > is the "xml:lang" attribute used in the error-message field. > > > > error-message: Contains a string suitable for human display = that > > describes the error condition. This element will not be = present > > if no appropriate message is provided for a particular error > > condition. This element SHOULD include an "xml:lang" = attribute as > > defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. > > > > > > We implement attributes in YANG with yet another YANG extension = called 'metadata'. > > It is used in the 'LangString' typedef to model = correctly. > > > > = http://www.netconfcentral.org/modules/yuma-netconf/2013-07-07#LangString.2= 15 > > > > The use of YANG extensions is problematic because they are = completely optional > > and outside the language (even the hack in RFC 6241). A = normative solution > > is needed. > > > > > > Proposed Solution: > > > > * A general mechanism is needed to declare data-specific and = typedef-specific metadata >=20 > Is it something else than Y33? >=20 >=20 > Yes -- as it says -- this is data-specific meta-data. > Note this text from issue Y33: >=20 > 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. >=20 > How does the client know which leafs use the xml:lang attribute? It may be attached to any element, not only leafs. This is how it works = in XML. > Which leafs have mandatory xml:lang attributes and which ones are = optional? So you want to model attributes in the same way as the XML schema = languages do? I think this would be a significant change to the design = of YANG - attributes were deliberately left out. Practically speaking, I can see the need for global attributes but not = for local ones. What are the use cases that cannot be modelled in YANG = now, e.g. via changing a leaf to a container? Lada >=20 > A top-level statement might be part of the solution for this problem. > I am just identifying the problem. >=20 >=20 > =20 > Lada >=20 >=20 >=20 > Andy > =20 > > > > > > Andy > > > > _______________________________________________ > > 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 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 29 12:32: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 0CCDF1A09B5 for ; Tue, 29 Apr 2014 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 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_38=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 6PXNBIwjPG8Q for ; Tue, 29 Apr 2014 12:32:21 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 568F11A04F1 for ; Tue, 29 Apr 2014 12:32:21 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j107so776533qga.28 for ; Tue, 29 Apr 2014 12:32: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=gd6X4+LHM3pZG6MHLJmeol3gSLgimyZXK0b/NQDLisQ=; b=f2FXhRCaFBec3U1fNbBsCsv4GT3ZgRjz/YQlcbT8ib/V/sEFkM4ylXDmFUnS/Lq1Tt PU5GODR599Col1ixzCRPbjxfj9GMMr/REOl4iRqD3LvQuE6eGT7KhfnX2Sa80Qp8BjS2 F13C0DfO26Saty5OnPwcI1GUgfV7qKCOsHdgmAzMS6cbjW8aKikgPzyQgeIk5lmWHOtq x8oaHgIEJzC9f8x7vfYdqrQVZccIG6w179/PHSXN3oG6LjtVBhN3E1yLVUdTNxg543uF ukI+ekl1GX0Ox+kjgBFORQwqfPMc67hOiZIhXebClzdJjZXfchzAjtlj3xTVTYFpRrBS +QtA== X-Gm-Message-State: ALoCoQkEU5e5cZWGYGsqKBqKgyw95MXrhqsz3cU098F2rjH6wiIbPri/8+wGa9wnuZ0kSQmJkqIy MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr1826815qge.34.1398799939935; Tue, 29 Apr 2014 12:32:19 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Tue, 29 Apr 2014 12:32:19 -0700 (PDT) In-Reply-To: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> References: <48141263-A153-403B-8E96-146A245E2F65@nic.cz> <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> Date: Tue, 29 Apr 2014 12:32:19 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113abfd888350b04f8337d21 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VyotiGyiGHeHN91-GzRg9kg03_4 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 29 Apr 2014 19:32:23 -0000 --001a113abfd888350b04f8337d21 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 29, 2014 at 11:52 AM, Ladislav Lhotka wrote: > > On 29 Apr 2014, at 20:35, Andy Bierman wrote: > > > > > > > > > On Tue, Apr 29, 2014 at 11:24 AM, Ladislav Lhotka wrote: > > > > On 29 Apr 2014, at 19:53, Andy Bierman wrote: > > > > > Hi, > > > > > > There is a need to support meta-data for data returned by a NETCONF > > > or RESTCONF server. YANG only supports attributes with hacks > > > like the operation in ietf-netconf.yang: > > > > > > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > > > > > > The most common attribute (that applies to a subset of all data > definitions) > > > is the "xml:lang" attribute used in the error-message field. > > > > > > error-message: Contains a string suitable for human display that > > > describes the error condition. This element will not be present > > > if no appropriate message is provided for a particular error > > > condition. This element SHOULD include an "xml:lang" attribute > as > > > defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. > > > > > > > > > We implement attributes in YANG with yet another YANG extension called > 'metadata'. > > > It is used in the 'LangString' typedef to model > correctly. > > > > > > > http://www.netconfcentral.org/modules/yuma-netconf/2013-07-07#LangString.215 > > > > > > The use of YANG extensions is problematic because they are completely > optional > > > and outside the language (even the hack in RFC 6241). A > normative solution > > > is needed. > > > > > > > > > Proposed Solution: > > > > > > * A general mechanism is needed to declare data-specific and > typedef-specific metadata > > > > Is it something else than Y33? > > > > > > Yes -- as it says -- this is data-specific meta-data. > > Note this text from issue Y33: > > > > 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. > > > > How does the client know which leafs use the xml:lang attribute? > > It may be attached to any element, not only leafs. This is how it works in > XML. > > I am talking about YANG schema. How XML works is not important. > > Which leafs have mandatory xml:lang attributes and which ones are > optional? > > So you want to model attributes in the same way as the XML schema > languages do? I think this would be a significant change to the design of > YANG - attributes were deliberately left out. > > I did not specify the syntax of any solution. The ncx:metadata uses 1 line. It is not XSD. Nobody suggesting using XSD. > Practically speaking, I can see the need for global attributes but not for > local ones. What are the use cases that cannot be modelled in YANG now, > e.g. via changing a leaf to a container? > > The global attribute is not that useful. Associating specific metadata with specific data nodes is more useful. Not all nodes are strings, so we have the YANG type-stmt to clarify the generic XML field. Not all strings are administrative strings that need the language identified. (So we need a sub-statement to specify that xml:lang attribute is expected). YANG parsers already have to accept a new subtree instead of ';' after every statement. The must-stmt has sub-trees. Adding a complex statement, if that was the solution, would not be any more complex than now. Lada > > Andy > > > > A top-level statement might be part of the solution for this problem. > > I am just identifying the problem. > > > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > > Andy > > > > > > _______________________________________________ > > > 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 > > > > > --001a113abfd888350b04f8337d21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 29, 2014 at 11:52 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

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

    >
    >
    >
    > On Tue, Apr 29, 2014 at 11:24 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
    >
    > On 29 Apr 2014, at 19:53, Andy Bierman <andy@yumaworks.com> wrote:
    >
    > > Hi,
    > >
    > > There is a need to support meta-data for data returned by a NETCO= NF
    > > or RESTCONF server. =A0YANG only supports attributes with hacks > > like the <get> operation in ietf-netconf.yang:
    > >
    > > http://www.netc= onfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attribute= s.56
    > >
    > > The most common attribute (that applies to a subset of all data d= efinitions)
    > > is the "xml:lang" attribute used in the error-message f= ield.
    > >
    > > =A0 =A0 =A0 error-message: =A0Contains a string suitable for huma= n display that
    > > =A0 =A0 =A0 describes the error condition. =A0This element will n= ot be present
    > > =A0 =A0 =A0 if no appropriate message is provided for a particula= r error
    > > =A0 =A0 =A0 condition. =A0This element SHOULD include an "xm= l:lang" attribute as
    > > =A0 =A0 =A0 defined in [W3C.REC-xml-20001006] and discussed in [R= FC3470].
    > >
    > >
    > > We implement attributes in YANG with yet another YANG extension c= alled 'metadata'.
    > > It is used in the 'LangString' typedef to model <error= -message> correctly.
    > >
    > > http://www.netconfcentral.org/mod= ules/yuma-netconf/2013-07-07#LangString.215
    > >
    > > The use of YANG extensions is problematic because they are comple= tely optional
    > > and outside the language (even the <get> hack in RFC 6241).= =A0A normative solution
    > > is needed.
    > >
    > >
    > > Proposed Solution:
    > >
    > > =A0 * A general mechanism is needed to declare data-specific and = typedef-specific metadata
    >
    > Is it something else than Y33?
    >
    >
    > Yes -- as it says -- this is data-specific meta-data.
    > Note this text from issue Y33:
    >
    > =A0 A new YANG statement, 'attribute', is proposed to allow de= fining such
    > =A0 attributes. It would be allowed only at the top level of a module = so
    > =A0 that it could be used for defining global attributes that can be > =A0 attached to any data node.
    >
    > How does the client know which leafs use the xml:lang attribute?

    It may be attached to any element, not only leafs. This is how it works in = XML.


    I am talking about YANG schema. How XM= L works is not important.

    =A0
    > Which leafs have mandatory xml:lang attributes and which ones are opti= onal?

    So you want to model attributes in the same way as the XML schema languages= do? I think this would be a significant change to the design of YANG - att= ributes were deliberately left out.


    I did not specify the syntax of any so= lution.
    The ncx:metadata uses 1 line. =A0It is not XSD.
    Nobody suggesting using XSD.

    =A0
    Practically speaking, I can see the need for global attributes but not for = local ones. What are the use cases that cannot be modelled in YANG now, e.g= . via changing a leaf to a container?


    The global attribute is not that usefu= l.
    Associating specific metadata with specific data nodes is more= useful.

    Not all nodes are strings, so we have the= YANG type-stmt
    to clarify the generic XML field. Not all strings are administrative
    strings that need the language identified. (So we need a sub-state= ment
    to specify that xml:lang attribute is expected).

    YANG parsers already have to accept a new subtree instead of= ';'
    after every statement. The must-stmt has sub-trees. = =A0Adding a complex
    statement, if that was the solution, would no= t be any more complex than now.



    Lada



    Andy
    =A0
    >
    > A top-level statement might be part of the solution for this problem.<= br> > I am just identifying the problem.
    >
    >
    >
    > Lada
    >
    >
    >
    > Andy
    >
    > >
    > >
    > > Andy
    > >
    > > _______________________________________________
    > > 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





    --001a113abfd888350b04f8337d21-- From nobody Tue Apr 29 13:05: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 9010E1A097F for ; Tue, 29 Apr 2014 13:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 xBaFBH01n9HN for ; Tue, 29 Apr 2014 13:05:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id DDAD91A098F for ; Tue, 29 Apr 2014 13:05: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 EDC453F4007; Tue, 29 Apr 2014 22:05:05 +0200 (CEST) Date: Tue, 29 Apr 2014 22:05:05 +0200 (CEST) Message-Id: <20140429.220505.221212226.mbj@tail-f.com> To: ietf-ssh@NetBSD.org From: Martin Bjorklund 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/I5it0TXGL4sL00529qZmz6jCCPs Cc: netmod@ietf.org Subject: [netmod] SSH keys - draft-ietf-netmod-system-mgmt 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, 29 Apr 2014 20:05:25 -0000 Hi, The NETMOD WG has produced draft-ietf-netmod-system-mgmt-15, which contains a YANG data model for system management. This document today enters a second IETF Last Call. Among other things, it has a data model for the definition of SSH public keys for local users on a device. Stephen Farrell suggested that this list might be able to help us with an SSH-specific question. We would be very grateful for any expert help. First some background. The data model in question has this structure (objects unrelated to SSH keys removed) +--rw user* [name] +--rw name string +--rw ssh-key* [name] +--rw name string +--rw algorithm string +--rw key-data binary This means that there is a list of users, identified by name. Each user has a list of public SSH keys, identified by an arbitrary name. Zooming in on the ssh-key list, it looks like this: list ssh-key { key name; description "A list of public SSH keys for this user."; reference "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; leaf name { type string; description "An arbitrary name for the ssh key."; } leaf algorithm { type string; mandatory true; description "The public key algorithm name for this ssh key. Valid values are the values in the IANA Secure Shell (SSH) Protocol Parameters registry, Public Key Algorithm Names"; reference "IANA Secure Shell (SSH) Protocol Parameters registry, Public Key Algorithm Names"; } leaf key-data { type binary; mandatory true; description "The binary key data for this ssh key."; } } Now to the problem. During implementation of ssh key handling, we realized that the description of these objects need at least some clarification. The intention was that the separation of the key with two leafs, "algorithm" and "key-data" makes it easy to cut-and-paste from keys generated with ssh-keygen etc. (The encoding of type binary in YANG is base64, which happen to match the key format. So the operator can set the "algorithm" and pase the base64 encoded blob into "key-data".) First of all, it is not entirely clear what goes into the "key-data" leaf. Common file formats (open ssh proprietary, RFC4716) follow the same rules; defined in RFC4716: The body of a public key file is the base64 encoded ([RFC2045]) public key data as specified by [RFC4253], Section 6.6: string certificate or public key format identifier byte[n] key/certificate data The open ssh internal format is this: e.g.: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBNX... The base64 blob is encoded as described above, i.e. it contains the string "ssh-rsa", even though this is already specified at the start of the line. So this format is redundant, and it seems the implementation detects and rejects keys that have different values for the and the public key format identifier. The RFC 4716 format does not have this redundancy: ---- BEGIN SSH2 PUBLIC KEY ---- AAAAB3NzaC1yc2EAAAADAQABAAABAQDBNX... ... ---- END SSH2 PUBLIC KEY ---- So we have some options: 1) Clarify that the leaf "key-data" contains: string certificate or public key format identifier byte[n] key/certificate data This allows for simple copy-and-paste from normal open ssh and rfc4716 files. However, if we also keep the leaf algorithm, we need to specify what happens if the leaf algorithm has a value that is different from the value embedded in the key blob. 2) Like 1, but remove the "leaf algorithm". 3) Keep "leaf algorithm" and specify that the leaf "key-data" contains: byte[n] key/certificate data This is NOT copy-and-paste friendly and probably pretty confusing to operators. Some other issues, probably less important. o If we do 1 or 2 above, is the name "key-data" really correct; shouldn't it be changed to just "key", in order to use the same terminology as RFC 4253: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data Which says that a "key" is encoded as "format id" + "key data". o Should list "ssh-key" be called "ssh-public-key"? The description says it is public keys only, so shouldn't this be reflected in the name of the list? We are leaning towards option 2 above, and would very much appreciate any comments on this matter! /martin From nobody Tue Apr 29 17:22: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 7FF311A096E for ; Tue, 29 Apr 2014 17:22:30 -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 bkkuufthmioJ for ; Tue, 29 Apr 2014 17:22:29 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 339AC1A0290 for ; Tue, 29 Apr 2014 17:22:29 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ih12so950320qab.24 for ; Tue, 29 Apr 2014 17:22:27 -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=q6fwKannMTh16midDgV93O/ODMzSZ3lLKkYjs6vC420=; b=YzEGab0KAG9xa+k/KdMkF1ETgZGLK4L9KTgwNUncAfjv7RzYTNlrFhvON8B/GrEPtU WOqQdDRwLdXMiJYgU+32mtEElxVh1n9AxMEenbzmI4xobKqG9aSDZlHfAvGDdMBwhqix z5CwvU7xoNWX/yGtlEJuV75z7kfsTxkULBiZmj140evpUTHJiWtTmN4oN3OwnMyymEea cQD4/AX8CbZIok5bfvqQ+bZgEc7SVv3FPeoxTdSf3umObxcXzwrHW8A42EuuYftGceTO V4hsQmaCDEk94k9MvF2KsJGTQjgMkcRqWOxktpWvAzCUIDtTQIJZ0mCNGMYPCTaq7s3e rSdg== X-Gm-Message-State: ALoCoQnVcxS68ESe+liq32P0wjVQP4z/pe5+bIMnyNgFU6k77fA6TPoMMfkQQpjOTkwVBtp58TUK MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr1297928qai.16.1398817347688; Tue, 29 Apr 2014 17:22:27 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Tue, 29 Apr 2014 17:22:27 -0700 (PDT) Date: Tue, 29 Apr 2014 17:22:27 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c20e7a1d7de004f8378b71 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gZ36Rf4Q0z3h8O42uQ7tEBxeDho Subject: [netmod] YANG 1.1 issue: bit name too restrictive 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, 30 Apr 2014 00:22:30 -0000 --001a11c20e7a1d7de004f8378b71 Content-Type: text/plain; charset=ISO-8859-1 Hi, The bit name is considered an 'identifier-arg-str' in the YANG ABNF. identifier-arg-str = < a string that matches the rule identifier-arg > identifier-arg = identifier ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") Problem: bit name does not need to be restricted in this manner because the bit names are never used as element or attribute names. They are only used as content in string nodes. Solution: change the syntax so it is less restrictive. Each bit must be a single token of printable chars without any whitespace. Andy --001a11c20e7a1d7de004f8378b71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    The bit name is consider= ed an 'identifier-arg-str' in the YANG ABNF.

      identifier-arg-str  =3D < a string that matches the rule
                           identifier-arg >

   identifier-arg      =3D identifier

   ;; An identifier MUST NOT start with (('X'|'x') ('M&=
#39;|'m') ('L'|'l'))
   identifier          =3D (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / =
".")

    Problem: bit name does not need to be restricted in= this manner
    because the bit names are never used as element or a= ttribute names.
    They are only used as content in string nodes.

    Solution: change the syntax so it is less restrictive. =A0Each bit must b= e a
    single token of printable chars without any whitespace.


    Andy

    --001a11c20e7a1d7de004f8378b71-- From nobody Tue Apr 29 18:12: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 2638A1A09BB for ; Tue, 29 Apr 2014 18:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.651 X-Spam-Level: X-Spam-Status: No, score=-100.651 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] 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 JHbPwy8iZtqd for ; Tue, 29 Apr 2014 18:12:02 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6191A09BA for ; Tue, 29 Apr 2014 18:12:02 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 1EDE118EB291 for ; Wed, 30 Apr 2014 09:11:50 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 846DDCCDCCF for ; Wed, 30 Apr 2014 09:11:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s3U1Bm0I032467 for ; Wed, 30 Apr 2014 09:11:48 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) To: netmod@ietf.org MIME-Version: 1.0 X-KeepSent: ADE35010:09DFFB02-48257CCA:00040A19; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Wed, 30 Apr 2014 09:11:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-04-30 09:11:48, Serialize complete at 2014-04-30 09:11:48 Content-Type: multipart/alternative; boundary="=_alternative 000692D548257CCA_=" X-MAIL: mse01.zte.com.cn s3U1Bm0I032467 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SFL0FQGRAt_izAu9HURTN1H-9k4 Subject: [netmod] YANG1.1 issue:add 'dataset' and 'datastore' statements 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, 30 Apr 2014 01:12:06 -0000 This is a multipart message in MIME format. --=_alternative 000692D548257CCA_= Content-Type: text/plain; charset="US-ASCII" Hi all, I suggest add 'dataset' and 'datastore' statements to identify which dataset a data node belongs to. YANG use config statement to identify whether the node belongsto configuration dataset, but it is not extensible. For example, I2RS want to define its own dataset, but YANG have no syntax to identify which node belongs to I2RS dataset, unless I2RS extend its own yang keyword. I think we should provide a standard way to de this. 'dataset' statement can be used to define a user-specific dataset. and a new statement 'belongs' can be used to identify which dataset the data node belongs to, as substatement of data nodes(container,list,leaf,leaf-list,anyxml,etc). 'datastore' statement can be used to define a data store based on one dataset. dataset statement's substatements are listed below: substatement cardinality description 0..1 reference 0..1 datastore statement's substatements are listed below: substatement cardinality base 1 description 0..1 reference 0..1 The 'base' statement has a argument,its value is a defined dataset, to indicate which dataset this datastore is based. For example: dataset config { description "the configuration dataset"; } datastore running { base config; description "running configuration data store"; } dataset i2rs { description "i2rs data set"; } datastore i2rs { base i2rs; } container foo { belongs config; list foo-list { belongs i2rs; key name; leaf name {...} leaf other {...} } } /frank -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 000692D548257CCA_= Content-Type: text/html; charset="US-ASCII" Hi all,
          I suggest add 'dataset' and 'datastore' statements to identify which dataset a data node belongs to.
          YANG use config statement to identify whether the node belongsto configuration dataset, but it is not extensible.
         
          For example, I2RS want to define its own dataset, but YANG have no syntax to identify which node belongs to I2RS dataset,
          unless I2RS extend its own yang keyword.

          I think we should provide a standard way to de this.
         
          'dataset' statement can be used to define a user-specific dataset. and a new statement 'belongs' can be used to identify which dataset
           the data node belongs to, as substatement of data nodes(container,list,leaf,leaf-list,anyxml,etc).
         
          'datastore' statement can be used to define a data store based on one dataset.
         
          dataset statement's substatements are listed below:
         
    substatement
    cardinality
    description
    0..1
    reference
    0..1


         datastore statement's substatements are listed below:
         
    substatement
    cardinality
    base
    1
    description
    0..1
    reference
    0..1


         The 'base' statement has a argument,its value is a defined dataset, to indicate which dataset this datastore is based.

         For example:
         dataset config {
            description "the configuration dataset";
         }

         datastore running {
            base config;
            description "running configuration data store";
         }
         
         dataset i2rs {
             description "i2rs data set";
         }
         
         datastore i2rs {
             base i2rs;
         }

         container foo {
            belongs config;
           list foo-list {
                belongs i2rs;
                key name;
                leaf name {...}
                leaf other {...}
           }
         }

    /frank 
    
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.




    
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

    --=_alternative 000692D548257CCA_=-- From nobody Tue Apr 29 18:23: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 73C081A09B0 for ; Tue, 29 Apr 2014 18:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jOJzjBNUp0DP for ; Tue, 29 Apr 2014 18:23:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 5181B1A0909 for ; Tue, 29 Apr 2014 18:23:21 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 30 Apr 2014 01:23:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.186]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.186]) with mapi id 15.00.0934.000; Wed, 30 Apr 2014 01:23:17 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt Thread-Index: AQHPY3s4jQ4Ilm00G0yRQcHkptQdJ5spG4CA Date: Wed, 30 Apr 2014 01:23:16 +0000 Message-ID: References: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> In-Reply-To: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(479174003)(377454003)(164054003)(377424004)(189002)(199002)(24454002)(81342001)(4396001)(101416001)(87936001)(77982001)(15975445006)(80976001)(83506001)(81542001)(2656002)(19580395003)(36756003)(92566001)(86362001)(15202345003)(99396002)(85852003)(74662001)(80022001)(79102001)(54356999)(83322001)(76482001)(20776003)(50986999)(76176999)(92726001)(46102001)(74502001)(19580405001)(83072002)(31966008)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:3CC5FDCD.90F2EFC1.B5E11F7F.4EE1E1C9.2028F; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <677E7DAD70B1AC4BA04B3F5A3696361E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QzRal4yO-gfk6Z13iOnO3-rwEf0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.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: Wed, 30 Apr 2014 01:23:25 -0000 I noticed this draft up for Last Call again and yet the issues raised here haven=B9t been addressed yet: http://www.ietf.org/mail-archive/web/netconf/current/msg08848.html Now I see that we have another go at a Last Call for this draft, can we please fix these issue this time? It doesn=B9t make sense to have these things configured in the netconf-server-model draft... Thanks, Kent On 4/29/14, 3:17 AM, "internet-drafts@ietf.org" wrote: > >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-15.txt > Pages : 40 > Date : 2014-04-29 > >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-15 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-15 > > >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/ > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 29 23:00: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 C430B1A6EE0 for ; Tue, 29 Apr 2014 23:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 8wfF0u27BOJ4 for ; Tue, 29 Apr 2014 23:00:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id D97781A09C5 for ; Tue, 29 Apr 2014 23:00:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B1AC7FF6; Wed, 30 Apr 2014 08:00:13 +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 IXTIVEZbLDLS; Wed, 30 Apr 2014 08:00:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 08:00:12 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AFAA20034; Wed, 30 Apr 2014 08:00:12 +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 UurMEN5-F70B; Wed, 30 Apr 2014 08:00: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 A0A5520043; Wed, 30 Apr 2014 08:00:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 24C5D2CC502C; Wed, 30 Apr 2014 08:00:06 +0200 (CEST) Date: Wed, 30 Apr 2014 08:00:03 +0200 From: Juergen Schoenwaelder To: feng.chong33@zte.com.cn Message-ID: <20140430060001.GA29852@elstar.local> Mail-Followup-To: feng.chong33@zte.com.cn, 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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/frHcC-VAO_Td3DcxAast7V8vzAY Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue:add 'dataset' and 'datastore' statements 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: Wed, 30 Apr 2014 06:00:26 -0000 I think the examples show a misconception about how YANG works and a likely typical misuse of a mechanism to define 'dataset's and 'datastores'. I think it would be a mistake to designate say a leaf definition as belonging to the running datastore instead of marking it as a config object. So far, we distinguish configuration objects from operational state objects. What we are missing seems to be the distinction between read-only operational state objects and operational state objects that can be written. I may be very wrong to allow data model writers to come up with arbitrary such distinctions. In other words, a proposal to introduce a mechanism to identify writable operational state is one thing (if it comes along with a clear understanding what the impact of this is on the whole NETCONF/YANG infrastructure). But a proposal to to allow an open ended set of object classes and datastores seems not very useful. /js (speaking as technical contributor) On Wed, Apr 30, 2014 at 09:11:25AM +0800, feng.chong33@zte.com.cn wrote: > Hi all, > I suggest add 'dataset' and 'datastore' statements to identify which > dataset a data node belongs to. > YANG use config statement to identify whether the node belongsto > configuration dataset, but it is not extensible. > > For example, I2RS want to define its own dataset, but YANG have no > syntax to identify which node belongs to I2RS dataset, > unless I2RS extend its own yang keyword. > > I think we should provide a standard way to de this. > > 'dataset' statement can be used to define a user-specific dataset. > and a new statement 'belongs' can be used to identify which dataset > the data node belongs to, as substatement of data > nodes(container,list,leaf,leaf-list,anyxml,etc). > > 'datastore' statement can be used to define a data store based on > one dataset. > > dataset statement's substatements are listed below: > > substatement > cardinality > description > 0..1 > reference > 0..1 > > datastore statement's substatements are listed below: > > substatement > cardinality > base > 1 > description > 0..1 > reference > 0..1 > > The 'base' statement has a argument,its value is a defined dataset, > to indicate which dataset this datastore is based. > > For example: > dataset config { > description "the configuration dataset"; > } > > datastore running { > base config; > description "running configuration data store"; > } > > dataset i2rs { > description "i2rs data set"; > } > > datastore i2rs { > base i2rs; > } > > container foo { > belongs config; > list foo-list { > belongs i2rs; > key name; > leaf name {...} > leaf other {...} > } > } > > /frank > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > _______________________________________________ > 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 29 23:02:53 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 3FA281A09DF for ; Tue, 29 Apr 2014 23:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 Jeb1TX3dae8I for ; Tue, 29 Apr 2014 23:02: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 6C7B91A09C5 for ; Tue, 29 Apr 2014 23:02:42 -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 320B43941D7; Wed, 30 Apr 2014 08:02:40 +0200 (CEST) Date: Wed, 30 Apr 2014 08:02:39 +0200 (CEST) Message-Id: <20140430.080239.483121657.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: 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/VgJfgc2sfqqQyWA6Qlq468-RYZ4 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 06:02:46 -0000 Hi, Added as Y46. /martin Andy Bierman wrote: > Hi, > > There is a need to support meta-data for data returned by a NETCONF > or RESTCONF server. YANG only supports attributes with hacks > like the operation in ietf-netconf.yang: > > http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 > > The most common attribute (that applies to a subset of all data definitions) > is the "xml:lang" attribute used in the error-message field. > > error-message: Contains a string suitable for human display that > describes the error condition. This element will not be present > if no appropriate message is provided for a particular error > condition. This element SHOULD include an "xml:lang" attribute as > defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. > > > We implement attributes in YANG with yet another YANG extension called > 'metadata'. > It is used in the 'LangString' typedef to model correctly. > > http://www.netconfcentral.org/modules/yuma-netconf/2013-07-07#LangString.215 > > The use of YANG extensions is problematic because they are completely > optional > and outside the language (even the hack in RFC 6241). A normative > solution > is needed. > > > Proposed Solution: > > * A general mechanism is needed to declare data-specific and > typedef-specific metadata > > > > Andy From nobody Tue Apr 29 23:03: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 61F8B1A6EEE for ; Tue, 29 Apr 2014 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 oZ1zuDf-ab91 for ; Tue, 29 Apr 2014 23:03: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 F1BE11A6EE5 for ; Tue, 29 Apr 2014 23:02:57 -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 3308E574001; Wed, 30 Apr 2014 08:02:56 +0200 (CEST) Date: Wed, 30 Apr 2014 08:02:55 +0200 (CEST) Message-Id: <20140430.080255.406864093.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: 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/wcOzUaxeWz2IMwVUGSYfXEd4RJU Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: bit name too restrictive 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, 30 Apr 2014 06:03:03 -0000 Hi, Added as Y47. Andy Bierman wrote: > Hi, > > The bit name is considered an 'identifier-arg-str' in the YANG ABNF. > > identifier-arg-str = < a string that matches the rule > identifier-arg > > > identifier-arg = identifier > > ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) > identifier = (ALPHA / "_") > *(ALPHA / DIGIT / "_" / "-" / ".") > > > Problem: bit name does not need to be restricted in this manner > because the bit names are never used as element or attribute names. > They are only used as content in string nodes. > > Solution: change the syntax so it is less restrictive. Each bit must be a > single token of printable chars without any whitespace. > > > Andy From nobody Tue Apr 29 23:03: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 340A31A6EE2 for ; Tue, 29 Apr 2014 23:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 ubCe655f3vUV for ; Tue, 29 Apr 2014 23:03: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 26F351A09C5 for ; Tue, 29 Apr 2014 23:03: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 6E7173941D7; Wed, 30 Apr 2014 08:03:35 +0200 (CEST) Date: Wed, 30 Apr 2014 08:03:34 +0200 (CEST) Message-Id: <20140430.080334.89777294.mbj@tail-f.com> To: feng.chong33@zte.com.cn From: Martin Bjorklund In-Reply-To: References: 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/mXfYBGl_5_apPnXyFJZMVwR9vl0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG1.1 issue:add 'dataset' and 'datastore' statements 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, 30 Apr 2014 06:03:40 -0000 Hi, I added this as an alternative solution to Y42; Y42-02. /martin feng.chong33@zte.com.cn wrote: > Hi all, > I suggest add 'dataset' and 'datastore' statements to identify which > dataset a data node belongs to. > YANG use config statement to identify whether the node belongsto > configuration dataset, but it is not extensible. > > For example, I2RS want to define its own dataset, but YANG have no > syntax to identify which node belongs to I2RS dataset, > unless I2RS extend its own yang keyword. > > I think we should provide a standard way to de this. > > 'dataset' statement can be used to define a user-specific dataset. > and a new statement 'belongs' can be used to identify which dataset > the data node belongs to, as substatement of data > nodes(container,list,leaf,leaf-list,anyxml,etc). > > 'datastore' statement can be used to define a data store based on > one dataset. > > dataset statement's substatements are listed below: > > substatement > cardinality > description > 0..1 > reference > 0..1 > > datastore statement's substatements are listed below: > > substatement > cardinality > base > 1 > description > 0..1 > reference > 0..1 > > The 'base' statement has a argument,its value is a defined dataset, > to indicate which dataset this datastore is based. > > For example: > dataset config { > description "the configuration dataset"; > } > > datastore running { > base config; > description "running configuration data store"; > } > > dataset i2rs { > description "i2rs data set"; > } > > datastore i2rs { > base i2rs; > } > > container foo { > belongs config; > list foo-list { > belongs i2rs; > key name; > leaf name {...} > leaf other {...} > } > } > > /frank > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and > any attachment transmitted herewith) is privileged and confidential and is > intended for the exclusive use of the addressee(s). If you are not an intended > recipient, any disclosure, reproduction, distribution or other dissemination or > use of the information contained is strictly prohibited. If you have received > this mail in error, please delete it and notify us immediately. > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and > any attachment transmitted herewith) is privileged and confidential and is > intended for the exclusive use of the addressee(s). If you are not an intended > recipient, any disclosure, reproduction, distribution or other dissemination or > use of the information contained is strictly prohibited. If you have received > this mail in error, please delete it and notify us immediately. From nobody Tue Apr 29 23:21: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 CE2081A6EEF for ; Tue, 29 Apr 2014 23:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.4 X-Spam-Level: X-Spam-Status: No, score=-95.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] 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 vM6VO_MHyzky for ; Tue, 29 Apr 2014 23:21:06 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 171441A6EEE for ; Tue, 29 Apr 2014 23:21:06 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id D89831251126; Wed, 30 Apr 2014 14:20:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s3U6KnhO064193; Wed, 30 Apr 2014 14:20:49 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20140430060001.GA29852@elstar.local> References: <20140430060001.GA29852@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-KeepSent: 034F6585:BB17F7CF-48257CCA:00217363; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Wed, 30 Apr 2014 14:20:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-04-30 14:20:51, Serialize complete at 2014-04-30 14:20:51 Content-Type: multipart/alternative; boundary="=_alternative 0022DE3348257CCA_=" X-MAIL: mse02.zte.com.cn s3U6KnhO064193 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PguRXcrq4e6U1KKbkN00ZgdckK4 Cc: netmod@ietf.org Subject: [netmod] =?gb2312?b?tPC4tDogUmU6ICBZQU5HMS4xIGlzc3VlOmFkZCAnZGF0?= =?gb2312?b?YXNldCcgYW5kICdkYXRhc3RvcmUnIHN0YXRlbWVudHM=?= 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, 30 Apr 2014 06:21:14 -0000 This is a multipart message in MIME format. --=_alternative 0022DE3348257CCA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 L2ZyYW5rDQoNCg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZT4gDQoyMDE0LTA0LTMwIDE0OjAwDQrH67TwuLQguPgNCkp1ZXJnZW4g U2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KDQoN CsrVvP7Iyw0KZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIA0Ks63LzQ0KbmV0bW9kQGlldGYub3Jn DQrW98ziDQpSZTogW25ldG1vZF0gWUFORzEuMSBpc3N1ZTphZGQgJ2RhdGFzZXQnIGFuZCAnZGF0 YXN0b3JlJyBzdGF0ZW1lbnRzDQoNCg0KDQoNCg0KDQpJIHRoaW5rIHRoZSBleGFtcGxlcyBzaG93 IGEgbWlzY29uY2VwdGlvbiBhYm91dCBob3cgWUFORyB3b3JrcyBhbmQgYQ0KbGlrZWx5IHR5cGlj YWwgbWlzdXNlIG9mIGEgbWVjaGFuaXNtIHRvIGRlZmluZSAnZGF0YXNldCdzIGFuZA0KJ2RhdGFz dG9yZXMnLiBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgbWlzdGFrZSB0byBkZXNpZ25hdGUgc2F5IGEg bGVhZg0KZGVmaW5pdGlvbiBhcyBiZWxvbmdpbmcgdG8gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIGlu c3RlYWQgb2YgbWFya2luZyBpdA0KYXMgYSBjb25maWcgb2JqZWN0Lg0KDQpObywgYSBkYXRhIG5v ZGUgbGlrZSBsZWFmIGJlbG9uZ3MgdG8gdGhlIGNvbmZpZyBkYXRhc2V0ICxub3QgcnVubmluZyAN CmRhdGFzdG9yZS4NCg0KRGF0YXN0b3JlIGlzIGp1c3QgYSBjb250YWluZXIgb2YgZGF0YXNldC4g RGF0YXN0b3JlIGlzIGEgZW50aXR5LCB3aGlsZSANCmRhdGFzZXQgaXMgYSBsb2dpY2FsIGNvbmNl cHRpb24uDQoNCg0KDQoNClNvIGZhciwgd2UgZGlzdGluZ3Vpc2ggY29uZmlndXJhdGlvbiBvYmpl Y3RzIGZyb20gb3BlcmF0aW9uYWwgc3RhdGUNCm9iamVjdHMuIFdoYXQgd2UgYXJlIG1pc3Npbmcg c2VlbXMgdG8gYmUgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4NCnJlYWQtb25seSBvcGVyYXRpb25h bCBzdGF0ZSBvYmplY3RzIGFuZCBvcGVyYXRpb25hbCBzdGF0ZSBvYmplY3RzIHRoYXQNCmNhbiBi ZSB3cml0dGVuLiBJIG1heSBiZSB2ZXJ5IHdyb25nIHRvIGFsbG93IGRhdGEgbW9kZWwgd3JpdGVy cyB0bw0KY29tZSB1cCB3aXRoIGFyYml0cmFyeSBzdWNoIGRpc3RpbmN0aW9ucy4NCg0KSSB0aGlu ayBjb25maWcodHJ1ZSBvciBmYWxzZSkgaXMgYSBjb25jZXB0aW9uIG9mIGNvbmZpZ3VyYXRpb24g bWFuYWdlbWVudC4NCkluIGNvbmZpZ3VyYXRpb24gbWFuYWdtZW50IGZpZWxkLCBhIGRhdGEgbm9k ZSB3aXRoIGNvbmZpZyBmYWxzZSBpcyANCnJlYWRvbmx5LCANCndoaWxlIGEgZGF0YSBub2RlIHdp dGggY29uZmlnIHRydWUgaXMgcmVhZHdyaXRlLiANCkJ1dCBpbiBvdGhlciBmaWVsZCxsaWtlIGky cnMsIGl0IG1heSBiZSBub3QuIEEgZGF0YSBub2RlIHdpdGggY29uZmlnIHRydWUgDQptYXkgYmUg cmVhZG9ubHkuIA0KDQpJbiBvdGhlciB3b3JkcywgYSBwcm9wb3NhbCB0byBpbnRyb2R1Y2UgYSBt ZWNoYW5pc20gdG8gaWRlbnRpZnkNCndyaXRhYmxlIG9wZXJhdGlvbmFsIHN0YXRlIGlzIG9uZSB0 aGluZyAoaWYgaXQgY29tZXMgYWxvbmcgd2l0aCBhDQpjbGVhciB1bmRlcnN0YW5kaW5nIHdoYXQg dGhlIGltcGFjdCBvZiB0aGlzIGlzIG9uIHRoZSB3aG9sZQ0KTkVUQ09ORi9ZQU5HIGluZnJhc3Ry dWN0dXJlKS4gQnV0IGEgcHJvcG9zYWwgdG8gdG8gYWxsb3cgYW4gb3BlbiBlbmRlZA0Kc2V0IG9m IG9iamVjdCBjbGFzc2VzIGFuZCBkYXRhc3RvcmVzIHNlZW1zIG5vdCB2ZXJ5IHVzZWZ1bC4NCg0K L2pzIChzcGVha2luZyBhcyB0ZWNobmljYWwgY29udHJpYnV0b3IpDQoNCk9uIFdlZCwgQXByIDMw LCAyMDE0IGF0IDA5OjExOjI1QU0gKzA4MDAsIGZlbmcuY2hvbmczM0B6dGUuY29tLmNuIHdyb3Rl Og0KPiBIaSBhbGwsDQo+ICAgICAgIEkgc3VnZ2VzdCBhZGQgJ2RhdGFzZXQnIGFuZCAnZGF0YXN0 b3JlJyBzdGF0ZW1lbnRzIHRvIGlkZW50aWZ5IA0Kd2hpY2ggDQo+IGRhdGFzZXQgYSBkYXRhIG5v ZGUgYmVsb25ncyB0by4NCj4gICAgICAgWUFORyB1c2UgY29uZmlnIHN0YXRlbWVudCB0byBpZGVu dGlmeSB3aGV0aGVyIHRoZSBub2RlIGJlbG9uZ3N0byANCj4gY29uZmlndXJhdGlvbiBkYXRhc2V0 LCBidXQgaXQgaXMgbm90IGV4dGVuc2libGUuDQo+IA0KPiAgICAgICBGb3IgZXhhbXBsZSwgSTJS UyB3YW50IHRvIGRlZmluZSBpdHMgb3duIGRhdGFzZXQsIGJ1dCBZQU5HIGhhdmUgbm8gDQoNCj4g c3ludGF4IHRvIGlkZW50aWZ5IHdoaWNoIG5vZGUgYmVsb25ncyB0byBJMlJTIGRhdGFzZXQsDQo+ ICAgICAgIHVubGVzcyBJMlJTIGV4dGVuZCBpdHMgb3duIHlhbmcga2V5d29yZC4NCj4gDQo+ICAg ICAgIEkgdGhpbmsgd2Ugc2hvdWxkIHByb3ZpZGUgYSBzdGFuZGFyZCB3YXkgdG8gZGUgdGhpcy4N Cj4gDQo+ICAgICAgICdkYXRhc2V0JyBzdGF0ZW1lbnQgY2FuIGJlIHVzZWQgdG8gZGVmaW5lIGEg dXNlci1zcGVjaWZpYyBkYXRhc2V0LiANCg0KPiBhbmQgYSBuZXcgc3RhdGVtZW50ICdiZWxvbmdz JyBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSB3aGljaCBkYXRhc2V0IA0KPiAgICAgICAgdGhlIGRh dGEgbm9kZSBiZWxvbmdzIHRvLCBhcyBzdWJzdGF0ZW1lbnQgb2YgZGF0YSANCj4gbm9kZXMoY29u dGFpbmVyLGxpc3QsbGVhZixsZWFmLWxpc3QsYW55eG1sLGV0YykuDQo+IA0KPiAgICAgICAnZGF0 YXN0b3JlJyBzdGF0ZW1lbnQgY2FuIGJlIHVzZWQgdG8gZGVmaW5lIGEgZGF0YSBzdG9yZSBiYXNl ZCBvbiANCj4gb25lIGRhdGFzZXQuDQo+IA0KPiAgICAgICBkYXRhc2V0IHN0YXRlbWVudCdzIHN1 YnN0YXRlbWVudHMgYXJlIGxpc3RlZCBiZWxvdzoNCj4gDQo+IHN1YnN0YXRlbWVudA0KPiBjYXJk aW5hbGl0eQ0KPiBkZXNjcmlwdGlvbg0KPiAwLi4xDQo+IHJlZmVyZW5jZQ0KPiAwLi4xDQo+IA0K PiAgICAgIGRhdGFzdG9yZSBzdGF0ZW1lbnQncyBzdWJzdGF0ZW1lbnRzIGFyZSBsaXN0ZWQgYmVs b3c6DQo+IA0KPiBzdWJzdGF0ZW1lbnQNCj4gY2FyZGluYWxpdHkNCj4gYmFzZQ0KPiAxDQo+IGRl c2NyaXB0aW9uDQo+IDAuLjENCj4gcmVmZXJlbmNlDQo+IDAuLjENCj4gDQo+ICAgICAgVGhlICdi YXNlJyBzdGF0ZW1lbnQgaGFzIGEgYXJndW1lbnQsaXRzIHZhbHVlIGlzIGEgZGVmaW5lZCBkYXRh c2V0LCANCg0KPiB0byBpbmRpY2F0ZSB3aGljaCBkYXRhc2V0IHRoaXMgZGF0YXN0b3JlIGlzIGJh c2VkLg0KPiANCj4gICAgICBGb3IgZXhhbXBsZToNCj4gICAgICBkYXRhc2V0IGNvbmZpZyB7DQo+ ICAgICAgICAgZGVzY3JpcHRpb24gInRoZSBjb25maWd1cmF0aW9uIGRhdGFzZXQiOw0KPiAgICAg IH0NCj4gDQo+ICAgICAgZGF0YXN0b3JlIHJ1bm5pbmcgew0KPiAgICAgICAgIGJhc2UgY29uZmln Ow0KPiAgICAgICAgIGRlc2NyaXB0aW9uICJydW5uaW5nIGNvbmZpZ3VyYXRpb24gZGF0YSBzdG9y ZSI7DQo+ICAgICAgfQ0KPiANCj4gICAgICBkYXRhc2V0IGkycnMgew0KPiAgICAgICAgICBkZXNj cmlwdGlvbiAiaTJycyBkYXRhIHNldCI7DQo+ICAgICAgfQ0KPiANCj4gICAgICBkYXRhc3RvcmUg aTJycyB7DQo+ICAgICAgICAgIGJhc2UgaTJyczsNCj4gICAgICB9DQo+IA0KPiAgICAgIGNvbnRh aW5lciBmb28gew0KPiAgICAgICAgIGJlbG9uZ3MgY29uZmlnOw0KPiAgICAgICAgbGlzdCBmb28t bGlzdCB7DQo+ICAgICAgICAgICAgIGJlbG9uZ3MgaTJyczsNCj4gICAgICAgICAgICAga2V5IG5h bWU7DQo+ICAgICAgICAgICAgIGxlYWYgbmFtZSB7Li4ufQ0KPiAgICAgICAgICAgICBsZWFmIG90 aGVyIHsuLi59DQo+ICAgICAgICB9DQo+ICAgICAgfQ0KPiANCj4gL2ZyYW5rDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg cHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIA0KYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgDQphbiBpbnRl bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlv biBvciBvdGhlciANCmRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmltbWVkaWF0 ZWx5Lg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0 ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IA0KYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3Rp ZnkgdXMgDQppbW1lZGlhdGVseS4NCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCi0t IA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVt ZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwg Mjg3NTkgQnJlbWVuLCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxo dHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFu ZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQg Y29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55 IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWlu YXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 0022DE3348257CCA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIg Jmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8L2I+DQo8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNC0wNC0zMCAxNDowMDwvZm9u dD4NCjx0YWJsZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0K PGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsfrtPC4tCC4 +Dxicj4NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlJmd0OzwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTYz JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmZlbmcuY2hvbmczM0B6dGUuY29t LmNuLCA8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm5ldG1vZEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UmU6IFtuZXRtb2RdIFlBTkcxLjEgaXNzdWU6YWRkICdkYXRhc2V0Jw0KYW5kICdkYXRhc3Rv cmUnIHN0YXRlbWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkkgdGhpbmsgdGhlIGV4YW1wbGVzIHNob3cgYSBtaXNjb25jZXB0aW9u IGFib3V0IGhvdw0KWUFORyB3b3JrcyBhbmQgYTxicj4NCmxpa2VseSB0eXBpY2FsIG1pc3VzZSBv ZiBhIG1lY2hhbmlzbSB0byBkZWZpbmUgJ2RhdGFzZXQncyBhbmQ8YnI+DQonZGF0YXN0b3Jlcycu IEkgdGhpbmsgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIGRlc2lnbmF0ZSBzYXkgYSBsZWFmPGJy Pg0KZGVmaW5pdGlvbiBhcyBiZWxvbmdpbmcgdG8gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIGluc3Rl YWQgb2YgbWFya2luZyBpdDxicj4NCmFzIGEgY29uZmlnIG9iamVjdC48YnI+DQo8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+Tm8sIGEgZGF0YSBub2RlIGxpa2Ug bGVhZiBiZWxvbmdzIHRvIHRoZQ0KY29uZmlnIGRhdGFzZXQgLG5vdCBydW5uaW5nIGRhdGFzdG9y ZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+RGF0 YXN0b3JlIGlzIGp1c3QgYSBjb250YWluZXIgb2YgZGF0YXNldC4NCkRhdGFzdG9yZSBpcyBhIGVu dGl0eSwgd2hpbGUgZGF0YXNldCBpcyBhIGxvZ2ljYWwgY29uY2VwdGlvbi48L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NClNvIGZhciwgd2Ug ZGlzdGluZ3Vpc2ggY29uZmlndXJhdGlvbiBvYmplY3RzIGZyb20gb3BlcmF0aW9uYWwgc3RhdGU8 YnI+DQpvYmplY3RzLiBXaGF0IHdlIGFyZSBtaXNzaW5nIHNlZW1zIHRvIGJlIHRoZSBkaXN0aW5j dGlvbiBiZXR3ZWVuPGJyPg0KcmVhZC1vbmx5IG9wZXJhdGlvbmFsIHN0YXRlIG9iamVjdHMgYW5k IG9wZXJhdGlvbmFsIHN0YXRlIG9iamVjdHMgdGhhdDxicj4NCmNhbiBiZSB3cml0dGVuLiBJIG1h eSBiZSB2ZXJ5IHdyb25nIHRvIGFsbG93IGRhdGEgbW9kZWwgd3JpdGVycyB0bzxicj4NCmNvbWUg dXAgd2l0aCBhcmJpdHJhcnkgc3VjaCBkaXN0aW5jdGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPkkgdGhpbmsgY29uZmlnKHRydWUgb3IgZmFs c2UpIGlzIGEgY29uY2VwdGlvbg0Kb2YgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50LjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5JbiBjb25maWd1cmF0aW9uIG1h bmFnbWVudCBmaWVsZCwgYSBkYXRhDQpub2RlIHdpdGggY29uZmlnIGZhbHNlIGlzIHJlYWRvbmx5 LCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+d2hpbGUgYSBk YXRhIG5vZGUgd2l0aCBjb25maWcgdHJ1ZSBpcyByZWFkd3JpdGUuDQo8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+QnV0IGluIG90aGVyIGZpZWxkLGxpa2UgaTJy cywgaXQgbWF5IGJlDQpub3QuIEEgZGF0YSBub2RlIHdpdGggY29uZmlnIHRydWUgbWF5IGJlIHJl YWRvbmx5LiA8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCkluIG90aGVy IHdvcmRzLCBhIHByb3Bvc2FsIHRvIGludHJvZHVjZSBhIG1lY2hhbmlzbSB0byBpZGVudGlmeTxi cj4NCndyaXRhYmxlIG9wZXJhdGlvbmFsIHN0YXRlIGlzIG9uZSB0aGluZyAoaWYgaXQgY29tZXMg YWxvbmcgd2l0aCBhPGJyPg0KY2xlYXIgdW5kZXJzdGFuZGluZyB3aGF0IHRoZSBpbXBhY3Qgb2Yg dGhpcyBpcyBvbiB0aGUgd2hvbGU8YnI+DQpORVRDT05GL1lBTkcgaW5mcmFzdHJ1Y3R1cmUpLiBC dXQgYSBwcm9wb3NhbCB0byB0byBhbGxvdyBhbiBvcGVuIGVuZGVkPGJyPg0Kc2V0IG9mIG9iamVj dCBjbGFzc2VzIGFuZCBkYXRhc3RvcmVzIHNlZW1zIG5vdCB2ZXJ5IHVzZWZ1bC48YnI+DQo8YnI+ DQovanMgKHNwZWFraW5nIGFzIHRlY2huaWNhbCBjb250cmlidXRvcik8YnI+DQo8YnI+DQpPbiBX ZWQsIEFwciAzMCwgMjAxNCBhdCAwOToxMToyNUFNICswODAwLCBmZW5nLmNob25nMzNAenRlLmNv bS5jbiB3cm90ZTo8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEkgc3VnZ2VzdCBhZGQgJ2RhdGFzZXQnIGFuZCAnZGF0YXN0b3JlJyBzdGF0ZW1lbnRzDQp0 byBpZGVudGlmeSB3aGljaCA8YnI+DQomZ3Q7IGRhdGFzZXQgYSBkYXRhIG5vZGUgYmVsb25ncyB0 by48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFlBTkcgdXNlIGNvbmZpZyBzdGF0ZW1l bnQgdG8gaWRlbnRpZnkgd2hldGhlcg0KdGhlIG5vZGUgYmVsb25nc3RvIDxicj4NCiZndDsgY29u ZmlndXJhdGlvbiBkYXRhc2V0LCBidXQgaXQgaXMgbm90IGV4dGVuc2libGUuPGJyPg0KJmd0OyAm bmJzcDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZvciBleGFtcGxlLCBJMlJTIHdh bnQgdG8gZGVmaW5lIGl0cyBvd24gZGF0YXNldCwNCmJ1dCBZQU5HIGhhdmUgbm8gPGJyPg0KJmd0 OyBzeW50YXggdG8gaWRlbnRpZnkgd2hpY2ggbm9kZSBiZWxvbmdzIHRvIEkyUlMgZGF0YXNldCw8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVubGVzcyBJMlJTIGV4dGVuZCBpdHMgb3du IHlhbmcga2V5d29yZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SSB0aGluayB3ZSBzaG91bGQgcHJvdmlkZSBhIHN0YW5kYXJkIHdheSB0byBkZQ0KdGhpcy48YnI+ DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJ2RhdGFzZXQnIHN0 YXRlbWVudCBjYW4gYmUgdXNlZCB0byBkZWZpbmUgYSB1c2VyLXNwZWNpZmljDQpkYXRhc2V0LiA8 YnI+DQomZ3Q7IGFuZCBhIG5ldyBzdGF0ZW1lbnQgJ2JlbG9uZ3MnIGNhbiBiZSB1c2VkIHRvIGlk ZW50aWZ5IHdoaWNoIGRhdGFzZXQNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dGhlIGRhdGEgbm9kZSBiZWxvbmdzIHRvLCBhcyBzdWJzdGF0ZW1lbnQNCm9mIGRhdGEgPGJy Pg0KJmd0OyBub2Rlcyhjb250YWluZXIsbGlzdCxsZWFmLGxlYWYtbGlzdCxhbnl4bWwsZXRjKS48 YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJ2RhdGFzdG9y ZScgc3RhdGVtZW50IGNhbiBiZSB1c2VkIHRvIGRlZmluZSBhDQpkYXRhIHN0b3JlIGJhc2VkIG9u IDxicj4NCiZndDsgb25lIGRhdGFzZXQuPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGRhdGFzZXQgc3RhdGVtZW50J3Mgc3Vic3RhdGVtZW50cyBhcmUgbGlz dGVkDQpiZWxvdzo8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgc3Vic3RhdGVtZW50PGJyPg0K Jmd0OyBjYXJkaW5hbGl0eTxicj4NCiZndDsgZGVzY3JpcHRpb248YnI+DQomZ3Q7IDAuLjE8YnI+ DQomZ3Q7IHJlZmVyZW5jZTxicj4NCiZndDsgMC4uMTxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwO2RhdGFzdG9yZSBzdGF0ZW1lbnQncyBzdWJzdGF0ZW1lbnRzIGFyZSBs aXN0ZWQNCmJlbG93Ojxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyBzdWJzdGF0ZW1lbnQ8YnI+ DQomZ3Q7IGNhcmRpbmFsaXR5PGJyPg0KJmd0OyBiYXNlPGJyPg0KJmd0OyAxPGJyPg0KJmd0OyBk ZXNjcmlwdGlvbjxicj4NCiZndDsgMC4uMTxicj4NCiZndDsgcmVmZXJlbmNlPGJyPg0KJmd0OyAw Li4xPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlICdiYXNlJyBz dGF0ZW1lbnQgaGFzIGEgYXJndW1lbnQsaXRzIHZhbHVlDQppcyBhIGRlZmluZWQgZGF0YXNldCwg PGJyPg0KJmd0OyB0byBpbmRpY2F0ZSB3aGljaCBkYXRhc2V0IHRoaXMgZGF0YXN0b3JlIGlzIGJh c2VkLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxl Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhc2V0IGNvbmZpZyB7PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7dGhlIGNvbmZp Z3VyYXRpb24gZGF0YXNldCZxdW90Ozs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxi cj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RhdGFzdG9yZSBydW5uaW5n IHs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiYXNlIGNvbmZpZzs8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtydW5u aW5nIGNvbmZpZ3VyYXRpb24NCmRhdGEgc3RvcmUmcXVvdDs7PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwO308YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkYXRhc2V0IGkycnMgezxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2Rlc2NyaXB0aW9uICZxdW90O2kycnMgZGF0YSBzZXQmcXVvdDs7PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtkYXRhc3RvcmUgaTJycyB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7YmFzZSBpMnJzOzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udGFpbmVyIGZvbyB7PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmVsb25ncyBjb25maWc7PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsaXN0IGZvby1saXN0IHs8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlbG9uZ3MgaTJyczs8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGtleSBu YW1lOzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg bGVhZiBuYW1lIHsuLi59PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBsZWFmIG90aGVyIHsuLi59PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt9PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7IDxicj4N CiZndDsgL2ZyYW5rPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQptYWlsIChhbmQgYW55 IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZp ZGVudGlhbA0KYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlKHMpLiAmbmJzcDtJZiB5b3UNCmFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBh bnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24NCm9yIG90aGVyIGRpc3Nl bWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkN CnByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJv ciwgcGxlYXNlIGRlbGV0ZQ0KaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQomZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMNCm1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRl ZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsDQphbmQgaXMgaW50ZW5k ZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lmIHlv dQ0KYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIGRpc3RyaWJ1dGlvbg0Kb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseQ0KcHJvaGliaXRlZC4gJm5ic3A7SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlDQppdCBh bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCjxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG5ldG1vZCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IG5ldG1vZEBpZXRmLm9yZzxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEg aHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZD48dHQ+PGZv bnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9m b250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0K SnVlcmdlbiBTY2hvZW53YWVsZGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SmFjb2JzIFVuaXZlcnNpdHkNCkJyZW1lbiBnR21iSDxicj4NClBob25lOiArNDkgNDIxIDIwMCAz NTg3ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYW1wdXMgUmluZyAxLCAyODc1OQ0KQnJl bWVuLCBHZXJtYW55PGJyPg0KRmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEwMyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuamFj b2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuamFjb2JzLXVu aXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4NCjwv Zm9udD48L3R0Pg0KPGJyPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90 aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBl cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2Zv bnQ+PC9wcmU+PGJyPg0K --=_alternative 0022DE3348257CCA_=-- From nobody Tue Apr 29 23:54: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 16FBB1A6EE8 for ; Tue, 29 Apr 2014 23:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] 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 JglrAgS8UJ4d for ; Tue, 29 Apr 2014 23:49:14 -0700 (PDT) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC31A6EEE for ; Tue, 29 Apr 2014 23:49:10 -0700 (PDT) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s3U6n732024476; Wed, 30 Apr 2014 08:49:07 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s3U6n6ZQ024475; Wed, 30 Apr 2014 08:49:06 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Martin Bjorklund References: <20140429.220505.221212226.mbj@tail-f.com> Date: Wed, 30 Apr 2014 08:49:06 +0200 In-Reply-To: <20140429.220505.221212226.mbj@tail-f.com> (Martin Bjorklund's message of "Tue, 29 Apr 2014 22:05:05 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jf4ahKtzaaLhgO1LIhbGMM0WPxY X-Mailman-Approved-At: Tue, 29 Apr 2014 23:54:03 -0700 Cc: ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt 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, 30 Apr 2014 06:49:16 -0000 Martin Bjorklund writes: > 1) Clarify that the leaf "key-data" contains: > > string certificate or public key format identifier > byte[n] key/certificate data > > This allows for simple copy-and-paste from normal open ssh and > rfc4716 files. > > However, if we also keep the leaf algorithm, we need to specify > what happens if the leaf algorithm has a value that is different > from the value embedded in the key blob. Right, eliminating this redundancy makes things simpler. > 2) Like 1, but remove the "leaf algorithm". I'm not sure I understand the context, but this sounds like the best option to me. If one wants a human-readable algorithm identifier, one could include that in the name field (but ideally, any tools handling this data should be able to extract the algorithm id from the key blob). > 3) Keep "leaf algorithm" and specify that the leaf "key-data" contains: > > byte[n] key/certificate data > > This is NOT copy-and-paste friendly and probably pretty > confusing to operators. I would recommend *not* picking apart the ssh key (unless you really want to convert it to some other reasonable representation, say, an spki-style s-expression). > Some other issues, probably less important. > > o If we do 1 or 2 above, is the name "key-data" really correct; > shouldn't it be changed to just "key", in order to use the same > terminology as RFC 4253: Makes sense. > o Should list "ssh-key" be called "ssh-public-key"? > > The description says it is public keys only, so shouldn't this be > reflected in the name of the list? I think it would make more sense to have a name that reflects the *purpose* of the list of keys, rather than just the data type. E.g., if it's authorization keys for logging in to the users account, it could be "authorized-ssh-keys" or something like that. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Wed Apr 30 00:46: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 D55811A011D for ; Wed, 30 Apr 2014 00:45:55 -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_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6] 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 t5Yu7rdCMLa9 for ; Wed, 30 Apr 2014 00:45:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D03BF1A07B9 for ; Wed, 30 Apr 2014 00:45:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 206095405EB; Wed, 30 Apr 2014 09:45:50 +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 d6w71VkxVF4I; Wed, 30 Apr 2014 09:45:44 +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 D1933540125; Wed, 30 Apr 2014 09:45:43 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <48141263-A153-403B-8E96-146A245E2F65@nic.cz> <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 30 Apr 2014 09:45:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NNg-6NN0SlV6V1OsGc_Tr8_bL84 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 07:45:56 -0000 Andy Bierman writes: > On Tue, Apr 29, 2014 at 11:52 AM, Ladislav Lhotka wrote: > >> >> On 29 Apr 2014, at 20:35, Andy Bierman wrote: >> >> > >> > >> > >> > On Tue, Apr 29, 2014 at 11:24 AM, Ladislav Lhotka wrote: >> > >> > On 29 Apr 2014, at 19:53, Andy Bierman wrote: >> > >> > > Hi, >> > > >> > > There is a need to support meta-data for data returned by a NETCONF >> > > or RESTCONF server. YANG only supports attributes with hacks >> > > like the operation in ietf-netconf.yang: >> > > >> > > >> http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56 >> > > >> > > The most common attribute (that applies to a subset of all data >> definitions) >> > > is the "xml:lang" attribute used in the error-message field. >> > > >> > > error-message: Contains a string suitable for human display that >> > > describes the error condition. This element will not be present >> > > if no appropriate message is provided for a particular error >> > > condition. This element SHOULD include an "xml:lang" attribute >> as >> > > defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. >> > > >> > > >> > > We implement attributes in YANG with yet another YANG extension called >> 'metadata'. >> > > It is used in the 'LangString' typedef to model >> correctly. >> > > >> > > >> http://www.netconfcentral.org/modules/yuma-netconf/2013-07-07#LangString.215 >> > > >> > > The use of YANG extensions is problematic because they are completely >> optional >> > > and outside the language (even the hack in RFC 6241). A >> normative solution >> > > is needed. >> > > >> > > >> > > Proposed Solution: >> > > >> > > * A general mechanism is needed to declare data-specific and >> typedef-specific metadata >> > >> > Is it something else than Y33? >> > >> > >> > Yes -- as it says -- this is data-specific meta-data. >> > Note this text from issue Y33: >> > >> > 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. >> > >> > How does the client know which leafs use the xml:lang attribute? >> >> It may be attached to any element, not only leafs. This is how it works in >> XML. >> >> > I am talking about YANG schema. How XML works is not important. You took xml:lang as a use case. The definition of error-message in RFC 4741 predated YANG, so xml:lang seemed to be a logical choice for specifying the language at that time. With YANG, it is not necessarily the case. > > > >> > Which leafs have mandatory xml:lang attributes and which ones are >> optional? >> >> So you want to model attributes in the same way as the XML schema >> languages do? I think this would be a significant change to the design of >> YANG - attributes were deliberately left out. >> >> > I did not specify the syntax of any solution. > The ncx:metadata uses 1 line. It is not XSD. > Nobody suggesting using XSD. > Neither do I - I am talking about making attributes first-class data modelling objects in YANG. > > >> Practically speaking, I can see the need for global attributes but not for >> local ones. What are the use cases that cannot be modelled in YANG now, >> e.g. via changing a leaf to a container? >> >> > The global attribute is not that useful. > Associating specific metadata with specific data nodes is more useful. Metadata associated with specific nodes can be modelled as standard YANG data nodes, perhaps using a grouping. My serious concern is that people will start using attributes as normal data nodes in YANG, for example 1.2.3.4 Extensive use of attributes is also rather unfriendly to JSON encoding. > > Not all nodes are strings, so we have the YANG type-stmt > to clarify the generic XML field. Not all strings are administrative > strings that need the language identified. (So we need a sub-statement > to specify that xml:lang attribute is expected). Nothing prevents you from using a language *leaf* where needed. For me, a typical use case for attributes is "inactive", which cannot be modelled this way. > > YANG parsers already have to accept a new subtree instead of ';' > after every statement. The must-stmt has sub-trees. Adding a complex > statement, if that was the solution, would not be any more complex than now. > Shall we end up with something as large as XSD and twice as natural? Lada > > > Lada >> >> > > Andy > > >> > >> > A top-level statement might be part of the solution for this problem. >> > I am just identifying the problem. >> > >> > >> > >> > Lada >> > >> > >> > >> > Andy >> > >> > > >> > > >> > > Andy >> > > >> > > _______________________________________________ >> > > 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 >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 30 01:00: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 02DD61A0317 for ; Wed, 30 Apr 2014 01:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 6Gn9PX4qJVXz for ; Wed, 30 Apr 2014 01:00:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8F61A015F for ; Wed, 30 Apr 2014 01:00:03 -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 F10D6574001; Wed, 30 Apr 2014 10:00:00 +0200 (CEST) Date: Wed, 30 Apr 2014 10:00:00 +0200 (CEST) Message-Id: <20140430.100000.412611390.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> 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/CySWj8AU01-9uWmILpHwfmCiyQE Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 08:00:07 -0000 Ladislav Lhotka wrote: > >> Practically speaking, I can see the need for global attributes but not for > >> local ones. What are the use cases that cannot be modelled in YANG now, > >> e.g. via changing a leaf to a container? > >> > >> > > The global attribute is not that useful. > > Associating specific metadata with specific data nodes is more useful. > > Metadata associated with specific nodes can be modelled as standard YANG data > nodes, perhaps using a grouping. But this it what we want to avoid... > My serious concern is that people will start using attributes as normal data > nodes in YANG +1 I agree with you that having a mechanism to define global meta data is the right way to go. It is quite simple, even if it doesn't solve all use cases as strict as you might like. data node specific meta data can be be handled with global meta data, even if it isn't as elegant. /martin From nobody Wed Apr 30 01:08: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 32A741A0317; Wed, 30 Apr 2014 01:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] 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 woumJJQmPgar; Wed, 30 Apr 2014 01:08:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A528F1A0155; Wed, 30 Apr 2014 01:08:25 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 044C1125182A; Wed, 30 Apr 2014 16:08:11 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 4DA55705A0E; Wed, 30 Apr 2014 16:08:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s3U889l7065836; Wed, 30 Apr 2014 16:08:09 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20140430.100000.412611390.mbj@tail-f.com> References: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> <20140430.100000.412611390.mbj@tail-f.com> To: Martin Bjorklund MIME-Version: 1.0 X-KeepSent: 3F3733A1:5A9761D0-48257CCA:002C6B19; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Wed, 30 Apr 2014 16:07:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-04-30 16:08:11, Serialize complete at 2014-04-30 16:08:11 Content-Type: multipart/alternative; boundary="=_alternative 002CAFF148257CCA_=" X-MAIL: mse01.zte.com.cn s3U889l7065836 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-IdjdGOZLl1dhW09JhW7C9X0o0k Cc: netmod , netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 08:08:31 -0000 This is a multipart message in MIME format. --=_alternative 002CAFF148257CCA_= Content-Type: text/plain; charset="US-ASCII" Ladislav Lhotka wrote: > >> Practically speaking, I can see the need for global attributes but not for > >> local ones. What are the use cases that cannot be modelled in YANG now, > >> e.g. via changing a leaf to a container? > >> > >> > > The global attribute is not that useful. > > Associating specific metadata with specific data nodes is more useful. > > Metadata associated with specific nodes can be modelled as standard YANG data > nodes, perhaps using a grouping. But this it what we want to avoid... > My serious concern is that people will start using attributes as normal data > nodes in YANG +1 I agree with you that having a mechanism to define global meta data is the right way to go. It is quite simple, even if it doesn't solve all use cases as strict as you might like. data node specific meta data can be be handled with global meta data, even if it isn't as elegant. /martin I suggest data node specific meta data must only be used in get opertion. global meta data can be used in set or get operation. /frank _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 002CAFF148257CCA_= Content-Type: text/html; charset="US-ASCII" Ladislav Lhotka <lhotka@nic.cz> wrote:
    > >> Practically speaking, I can see the need for global attributes but not for
    > >> local ones. What are the use cases that cannot be modelled in YANG now,
    > >> e.g. via changing a leaf to a container?
    > >>
    > >>
    > > The global attribute is not that useful.
    > > Associating specific metadata with specific data nodes is more useful.
    >
    > Metadata associated with specific nodes can be modelled as standard YANG data
    > nodes, perhaps using a grouping.

    But this it what we want to avoid...

    > My serious concern is that people will start using attributes as normal data
    > nodes in YANG

    +1

    I agree with you that having a mechanism to define global meta data is
    the right way to go.  It is quite simple, even if it doesn't solve all
    use cases as strict as you might like.  data node specific meta data
    can be be handled with global meta data, even if it isn't as elegant.


    /martin
    I suggest data node specific meta data  must only be used in get opertion.

    global meta data can be used in set or get operation.
    /frank
    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod
     


    
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.




    
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

    --=_alternative 002CAFF148257CCA_=-- From nobody Wed Apr 30 01:19: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 C8CFD1A6F14 for ; Wed, 30 Apr 2014 01:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 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.651] 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 pcXuHYat5wBz for ; Wed, 30 Apr 2014 01:19:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA181A6F11 for ; Wed, 30 Apr 2014 01:19:30 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B4091140504; Wed, 30 Apr 2014 10:19:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398845967; bh=HXslpwaS6N6pkXZldkwyult3FXdg70Mo/skx3LQ/IQs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gEzfkMMVTaNfoBwFtdg/NOjHtLmYhIl3agRyjxCdtURoqgat9VjQDMxnFhTUx1i5B sSInyvXcG389jR9NZ6SJ9jTDLdVl9k1Jt7jpD1ZTIWx1y+g9jlUoCr4lXodFRlW3qi nAlgBKRdD5VY7QAGXN87xEJbCvStGik20pc/Gs2w= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140430.100000.412611390.mbj@tail-f.com> Date: Wed, 30 Apr 2014 10:19:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8887FC39-AE73-475F-AB58-E0A04E9ABDBC@nic.cz> References: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> <20140430.100000.412611390.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/pcboTm0IKdMdFH_c5vO8H5rDczs Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 08:19:31 -0000 On 30 Apr 2014, at 10:00, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>>> Practically speaking, I can see the need for global attributes but = not for >>>> local ones. What are the use cases that cannot be modelled in YANG = now, >>>> e.g. via changing a leaf to a container? >>>>=20 >>>>=20 >>> The global attribute is not that useful. >>> Associating specific metadata with specific data nodes is more = useful. >>=20 >> Metadata associated with specific nodes can be modelled as standard = YANG data >> nodes, perhaps using a grouping. >=20 > But this it what we want to avoid=85 What=92s wrong with that? >=20 >> My serious concern is that people will start using attributes as = normal data >> nodes in YANG >=20 > +1 >=20 > I agree with you that having a mechanism to define global meta data is > the right way to go. It is quite simple, even if it doesn't solve all > use cases as strict as you might like. data node specific meta data > can be be handled with global meta data, even if it isn't as elegant. I guess it depends on how you define metadata. In a sense, =93inactive=94 = or =93nc:operation=94 is more =93meta=94 than say =93language=94 or = =93media-type=94. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 30 02:21: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 C2B3A1A6F1F for ; Wed, 30 Apr 2014 02:21:29 -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 KVGcA7UNqvVf for ; Wed, 30 Apr 2014 02:21:28 -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 0C2DB1A08B7 for ; Wed, 30 Apr 2014 02:21:20 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id j5so1558470qga.11 for ; Wed, 30 Apr 2014 02: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=QuS9DIoR64VsxHkppbKn78MVM09g9jH74L8QsfoJrJw=; b=EngEK24qJo524xttBH3DAMZ+B3yYPO0lGbLUmZlDbEVZEh3oI6DCQ+/ddvb7IeANvd nu+nRKLbQh9JEQudXPGZpMCbHutCdEdeYelGlNQhfRVnN5+jZbO+zDR4+JCejndiAPe2 6bb96Sf/iir8Ro3dkNUA6dV636rYUoJRX9hGVgeTxydR3+mbd+kol16P+1CufPS7gJTf sO6T12hQ0qHej3g9Huff2s4XvclFvo0Z1jx/EC+hE9eV7iZeD2qZ0E4HCX5pVBUr31Au bpzJnf2jCh3y3hs7R5bbmSflIqngjYOfa382fMpNeNf/A9vpRI/r7Wk+sAvPcJKhTAMt afQQ== X-Gm-Message-State: ALoCoQmKWo0WfAfajCbPBLfWHnJoO3HdP9LcVzQjjlOCddlRFQQs3/kSxu3nzAwB80yhbeZjvEQM MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr3427340qaa.7.1398849679405; Wed, 30 Apr 2014 02:21:19 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 02:21:19 -0700 (PDT) In-Reply-To: <8887FC39-AE73-475F-AB58-E0A04E9ABDBC@nic.cz> References: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> <20140430.100000.412611390.mbj@tail-f.com> <8887FC39-AE73-475F-AB58-E0A04E9ABDBC@nic.cz> Date: Wed, 30 Apr 2014 02:21:19 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bea39863c4a8704f83f122d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/q-zajWiYo6e-PmN4GvH5mnVAZ10 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 09:21:29 -0000 --047d7bea39863c4a8704f83f122d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 30, 2014 at 1:19 AM, Ladislav Lhotka wrote: > > On 30 Apr 2014, at 10:00, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >>>> Practically speaking, I can see the need for global attributes but > not for > >>>> local ones. What are the use cases that cannot be modelled in YANG > now, > >>>> e.g. via changing a leaf to a container? > >>>> > >>>> > >>> The global attribute is not that useful. > >>> Associating specific metadata with specific data nodes is more useful. > >> > >> Metadata associated with specific nodes can be modelled as standard > YANG data > >> nodes, perhaps using a grouping. > > > > But this it what we want to avoid... > > this is a strawman. The solution does not have to be inappropriate or abused. > What's wrong with that? > data model designers can decide what is appropriate > > > > >> My serious concern is that people will start using attributes as normal > data > >> nodes in YANG > > > > +1 > people could be designing containers when they should be using leafs. There are lots of ways one can make bad decisions with YANG. > > > > I agree with you that having a mechanism to define global meta data is > > the right way to go. It is quite simple, even if it doesn't solve all > > use cases as strict as you might like. data node specific meta data > > can be be handled with global meta data, even if it isn't as elegant. > > I guess it depends on how you define metadata. In a sense, "inactive" or > "nc:operation" is more "meta" than say "language" or "media-type". > very good - you picked another attribute that can apply globally. You are ignoring the 'language string' extension since it clearly does not apply to every data node. It is not XML-specific (see the NCX extension). Adding sibling leafs everywhere there is an admin string is not practical. The point of the YANG schema is to let the client know what the server will implement, such as which metadata will be returned for which nodes. Lada > > > > > > > /martin > > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7bea39863c4a8704f83f122d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 30, 2014 at 1:19 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

    On 30 Apr 2014, at 10:00, Martin Bjorklund <mbj@tail-f.com> wrote:

    > Ladislav Lhotka <lhotka@nic.cz= > wrote:
    >>>> Practically speaking, I can see the need for global attrib= utes but not for
    >>>> local ones. What are the use cases that cannot be modelled= in YANG now,
    >>>> e.g. via changing a leaf to a container?
    >>>>
    >>>>
    >>> The global attribute is not that useful.
    >>> Associating specific metadata with specific data nodes is more= useful.
    >>
    >> Metadata associated with specific nodes can be modelled as standar= d YANG data
    >> nodes, perhaps using a grouping.
    >
    > But this it what we want to avoid…


    this is a strawman.
    The solu= tion does not have to be inappropriate or abused.
     
    What’s wrong with that?

    data mode= l designers can decide what is appropriate
     

    >
    >> My serious concern is that people will start using attributes as n= ormal data
    >> nodes in YANG
    >
    > +1

    people could be designing conta= iners when they should be using leafs.
    There are lots of ways one= can make bad decisions with YANG.
     
    >
    > I agree with you that having a mechanism to define global meta data is=
    > the right way to go.  It is quite simple, even if it doesn't = solve all
    > use cases as strict as you might like.  data node specific meta d= ata
    > can be be handled with global meta data, even if it isn't as elega= nt.

    I guess it depends on how you define metadata. In a sense, “inactive&= rdquo; or “nc:operation” is more “meta” than say &l= dquo;language” or “media-type”.
    &nbs= p;

    very good - you picked another attribute that c= an apply globally.
    You are ignoring the 'language string' extension since it clea= rly does not apply
    to every data node.  It is not XML-specif= ic (see the NCX extension).
    Adding <language> sibling leafs= everywhere there is an admin string is not practical.

    The point of the YANG schema is to let the client know = what the server will implement,
    such as which metadata will be re= turned for which nodes.

    Lada

    >
    >
    > /martin



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





    --047d7bea39863c4a8704f83f122d-- From nobody Wed Apr 30 02:56: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 CDF401A08B6 for ; Wed, 30 Apr 2014 02:56: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 VZsIWv6iVD5v for ; Wed, 30 Apr 2014 02:56:24 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFAE1A08B0 for ; Wed, 30 Apr 2014 02:56:12 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id w8so1392000qac.19 for ; Wed, 30 Apr 2014 02:56:10 -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=VDnx8C1MPBBXLz3vCj2ojiCSwu6MyaOmf0F5wnspzgw=; b=BLMrbBPYYWZCyBnK4uysu2wMm7Xk4XUeTGJ2YCGDXtYMd5RvxSwAYgGm5txElfAIvk h1Has+WmS0IMEawQtupGUk/PJ65O/4gzdaDAf5109B3fyOiu1a6hWm2KHyZYvhmK/htS pzRn7TEyUP7iJpQSU58RyFqnNDpkvdHbZXf7CSfgeJs1nbJmcLEICGozX1tutdpQ/lQq YX6IFAb/Tn9ZNMoCgliI+Ym6liM0RwTlhlNrvkOnDtAWkGlByLc1yn6Jj/bR8FeKJ9Lb GcUOdxKJVLWK/h9Cls7TmMe2Rhnwrs3iznoiRpEhM+swwKqUwrX1r9g/e2rWvGYe/sIf yIhQ== X-Gm-Message-State: ALoCoQlXcHrmY7rTHBtRY9fnBHl+c04hRpoG2LwKXJB9/SehSleZ9ch8SU/t01Z+yy62srmm2hEW MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr3609428qaa.7.1398851770483; Wed, 30 Apr 2014 02:56:10 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 02:56:10 -0700 (PDT) In-Reply-To: <20140430.100000.412611390.mbj@tail-f.com> References: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> <20140430.100000.412611390.mbj@tail-f.com> Date: Wed, 30 Apr 2014 02:56:10 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bea3986df95e604f83f8edb Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UWiFxaB164VKn-SpzDupZhaiQ0A Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 09:56:27 -0000 --047d7bea3986df95e604f83f8edb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > >> Practically speaking, I can see the need for global attributes but > not for > > >> local ones. What are the use cases that cannot be modelled in YANG > now, > > >> e.g. via changing a leaf to a container? > > >> > > >> > > > The global attribute is not that useful. > > > Associating specific metadata with specific data nodes is more useful. > > > > Metadata associated with specific nodes can be modelled as standard YANG > data > > nodes, perhaps using a grouping. > > But this it what we want to avoid... > > > My serious concern is that people will start using attributes as normal > data > > nodes in YANG > > +1 > > I did not mention that these attributes are read-only, so it would be impossible to replace config leafs with attributes. This abuse you are concerned about is not possible. > I agree with you that having a mechanism to define global meta data is > the right way to go. It is quite simple, even if it doesn't solve all > use cases as strict as you might like. data node specific meta data > can be be handled with global meta data, even if it isn't as elegant. > > > /martin > Andy --047d7bea3986df95e604f83f8edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    Ladislav Lhotka <lhotka@nic.cz> wrote:
    > >> Practically speaking, I can see the need for global attribute= s but not for
    > >> local ones. What are the use cases that cannot be modelled in= YANG now,
    > >> e.g. via changing a leaf to a container?
    > >>
    > >>
    > > The global attribute is not that useful.
    > > Associating specific metadata with specific data nodes is more us= eful.
    >
    > Metadata associated with specific nodes can be modelled as standard YA= NG data
    > nodes, perhaps using a grouping.

    But this it what we want to avoid...

    > My serious concern is that people will start using attributes as norma= l data
    > nodes in YANG

    +1


    I did not mention that these attribute= s are read-only, so it would be impossible
    to replace config leaf= s with attributes. =A0This abuse you are concerned about
    is not p= ossible.

    =A0
    =A0
    I agree with you that having a mechanism to define global meta data is
    the right way to go. =A0It is quite simple, even if it doesn't solve al= l
    use cases as strict as you might like. =A0data node specific meta data
    can be be handled with global meta data, even if it isn't as elegant.

    /martin

    Andy<= /div>

    --047d7bea3986df95e604f83f8edb-- From nobody Wed Apr 30 03:04: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 B20A91A6F41 for ; Wed, 30 Apr 2014 03:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 SapvzFYKfkfA for ; Wed, 30 Apr 2014 03:04: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 ADDD01A08B6 for ; Wed, 30 Apr 2014 03:04:39 -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 8AEF2574001; Wed, 30 Apr 2014 12:04:37 +0200 (CEST) Date: Wed, 30 Apr 2014 12:04:37 +0200 (CEST) Message-Id: <20140430.120437.323948755.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140430.100000.412611390.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/niN3JoH0wMYlTTbTdTilqzB1JAM Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 10:04:42 -0000 Andy Bierman wrote: > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > >> Practically speaking, I can see the need for global attributes but > > not for > > > >> local ones. What are the use cases that cannot be modelled in YANG > > now, > > > >> e.g. via changing a leaf to a container? > > > >> > > > >> > > > > The global attribute is not that useful. > > > > Associating specific metadata with specific data nodes is more useful. > > > > > > Metadata associated with specific nodes can be modelled as standard YANG > > data > > > nodes, perhaps using a grouping. > > > > But this it what we want to avoid... > > > > > My serious concern is that people will start using attributes as normal > > data > > > nodes in YANG > > > > +1 > > > > > I did not mention that these attributes are read-only, so it would be > impossible > to replace config leafs with attributes. This abuse you are concerned about > is not possible. This seems like an arbitrary limitation. The "inactive" attribute is an example of a read/write (global) attribute. Why would data-node specific attributes be read only? For both global and local attributes, it must be possible to define their read/write properties. /martin From nobody Wed Apr 30 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 EA37D1A08BF for ; Wed, 30 Apr 2014 05:33:20 -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 q7Kf_KrBTypt for ; Wed, 30 Apr 2014 05:33:18 -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 CE03E1A0829 for ; Wed, 30 Apr 2014 05:33:17 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so208259qcx.41 for ; Wed, 30 Apr 2014 05:33:16 -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=eC3aoAbchNvvJ5lmXCbyRX7ZFJ92+pS0WOfDw8noO9k=; b=Wh/NJQoaR79SS+ls1yXMpRU3KzYzhml0wsRrhx+bKp8USJEKcrp/7cZJmwYcTW6J0F QXofjVy6x5rkxgwdbY2UQXIuxkkKUf14L2Q9QkwDtVkdR3TWhp90M6xe4duok8urE0VF m4bdd4oKRXqLZ4Q81ZNxT/P6+hk4oBJoW2Cnau7dQMNAUY98qBGr/H82rFNDe5et65YK BEGYNtESMxRDPONVnyCe4+KEkeDyVNKwwFyKZ/Op9FCq5So9oKw7z+35Lwd/dJuHx645 LRF2vvo87tPdCPmpsWmEZlqBcn5jwy6KJKmQcH1vw8S5DgTcqvb0mUUMUEGDGrxjJ+4e KWXw== X-Gm-Message-State: ALoCoQlR0M9pufkLFWnx7MKIJGNZaBHs5vBigOlBBkwtIS931Lt0/591EcgPrrk6+wz3q62psVMF MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr4464842qar.99.1398861196123; Wed, 30 Apr 2014 05:33:16 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 05:33:16 -0700 (PDT) In-Reply-To: <20140430.120437.323948755.mbj@tail-f.com> References: <20140430.100000.412611390.mbj@tail-f.com> <20140430.120437.323948755.mbj@tail-f.com> Date: Wed, 30 Apr 2014 05:33:16 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c30886af777d04f841c096 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6eVCc5tNNX2Ke_8d9SeQvgLb5TU Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 12:33:21 -0000 --001a11c30886af777d04f841c096 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund > wrote: > > > > > Ladislav Lhotka wrote: > > > > >> Practically speaking, I can see the need for global attributes but > > > not for > > > > >> local ones. What are the use cases that cannot be modelled in YANG > > > now, > > > > >> e.g. via changing a leaf to a container? > > > > >> > > > > >> > > > > > The global attribute is not that useful. > > > > > Associating specific metadata with specific data nodes is more > useful. > > > > > > > > Metadata associated with specific nodes can be modelled as standard > YANG > > > data > > > > nodes, perhaps using a grouping. > > > > > > But this it what we want to avoid... > > > > > > > My serious concern is that people will start using attributes as > normal > > > data > > > > nodes in YANG > > > > > > +1 > > > > > > > > I did not mention that these attributes are read-only, so it would be > > impossible > > to replace config leafs with attributes. This abuse you are concerned > about > > is not possible. > > This seems like an arbitrary limitation. The "inactive" attribute is > an example of a read/write (global) attribute. Why would data-node > specific attributes be read only? > > For both global and local attributes, it must be possible to define > their read/write properties. > > why is this mandatory for local? > > > /martin > --001a11c30886af777d04f841c096 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    Andy Bierman <andy@yumaworks.com> wrote:
    > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
    >
    > > Ladislav Lhotka <lhotka@nic.c= z> wrote:
    > > > >> Practically speaking, I can see the need for global= attributes but
    > > not for
    > > > >> local ones. What are the use cases that cannot be m= odelled in YANG
    > > now,
    > > > >> e.g. via changing a leaf to a container?
    > > > >>
    > > > >>
    > > > > The global attribute is not that useful.
    > > > > Associating specific metadata with specific data nodes = is more useful.
    > > >
    > > > Metadata associated with specific nodes can be modelled as s= tandard YANG
    > > data
    > > > nodes, perhaps using a grouping.
    > >
    > > But this it what we want to avoid...
    > >
    > > > My serious concern is that people will start using attribute= s as normal
    > > data
    > > > nodes in YANG
    > >
    > > +1
    > >
    > >
    > I did not mention that these attributes are read-only, so it would be<= br> > impossible
    > to replace config leafs with attributes. =A0This abuse you are concern= ed about
    > is not possible.

    This seems like an arbitrary limitation. =A0The "inactive" attrib= ute is
    an example of a read/write (global) attribute. =A0Why would data-node
    specific attributes be read only?

    For both global and local attributes, it must be possible to define
    their read/write properties.


    why is this mandatory for local?
    =A0
    =


    /martin

    --001a11c30886af777d04f841c096-- From nobody Wed Apr 30 05:48: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 944BE1A081B for ; Wed, 30 Apr 2014 05:48: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 p4m4fwAH4U-r for ; Wed, 30 Apr 2014 05:48:13 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id D332B1A6F63 for ; Wed, 30 Apr 2014 05:48:12 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so1745327qcq.37 for ; Wed, 30 Apr 2014 05:48:11 -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=bIlX/w9I0dosTrHfEO4282vRQ3hXvnxpjjHRPDmHyeQ=; b=J2Tw9Ho01HRholV2c/RKAk/m9PYoyXars0BwZ2sxlfghdQlm/iqSYlT4PheXoCLlKc CHc80cAkoqzY2mL8qdWhKx7Xz1XGHg0VSXTYjoPKmya+jw0PBWeI09N63Lh/ptKM/htb kwLiaD6XlXuFamDOTMKfKXQKBdMCJcgPckyqlnD7AY6GjbDbLc5KTJ59Tsb/JN+BG/9Y yqQ1z5UvJ0G3Xw0k+ZVhG70VTWVbWmua87i7kt7+KSWiLQMW5y7bmuTgLyDc0olrZyLG vjjf4xKzRpqTuTGmBwUirEuFVpe3OaMef8+3GKP8ZT4MiLyfeTvPJmCiBzMorpdo350n Zy6A== X-Gm-Message-State: ALoCoQnpzq3HSGH+LCzdoEhZ+F+Wxyok04eI8w8zq6kveEJe4qcbzwa4l111ov+Hmb7c7MwU6dbV MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr4779816qat.78.1398862091255; Wed, 30 Apr 2014 05:48:11 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 05:48:11 -0700 (PDT) In-Reply-To: <20140430.120437.323948755.mbj@tail-f.com> References: <20140430.100000.412611390.mbj@tail-f.com> <20140430.120437.323948755.mbj@tail-f.com> Date: Wed, 30 Apr 2014 05:48:11 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b672b440a38f304f841f6c6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kbSdvaC3XFTNBvZ4KrKcJxnOb_M Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 12:48:16 -0000 --047d7b672b440a38f304f841f6c6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund > wrote: > > > > > Ladislav Lhotka wrote: > > > > >> Practically speaking, I can see the need for global attributes but > > > not for > > > > >> local ones. What are the use cases that cannot be modelled in YANG > > > now, > > > > >> e.g. via changing a leaf to a container? > > > > >> > > > > >> > > > > > The global attribute is not that useful. > > > > > Associating specific metadata with specific data nodes is more > useful. > > > > > > > > Metadata associated with specific nodes can be modelled as standard > YANG > > > data > > > > nodes, perhaps using a grouping. > > > > > > But this it what we want to avoid... > > > > > > > My serious concern is that people will start using attributes as > normal > > > data > > > > nodes in YANG > > > > > > +1 > > > > > > > > I did not mention that these attributes are read-only, so it would be > > impossible > > to replace config leafs with attributes. This abuse you are concerned > about > > is not possible. > > This seems like an arbitrary limitation. The "inactive" attribute is > an example of a read/write (global) attribute. Why would data-node > specific attributes be read only? > > For both global and local attributes, it must be possible to define > their read/write properties. > So what is supposed to stop someone from defining "netmask" as a global attribute instead of a config leaf? Global vs. local is irrelevant, except global is worse because the YANG schema does not say the
    leaf is going to reject any edit that does not include the 'netmask' attribute. Using attributes for editing doesn't work. If you make a CLR that global attributes can't be "part of the data model", then the same CLR can be made for local attributes. > > > > /martin > Andy --047d7b672b440a38f304f841f6c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
    Andy Bierman <andy@yumaworks.com> wrote:
    > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
    >
    > > Ladislav Lhotka <lhotka@nic.c= z> wrote:
    > > > >> Practically speaking, I can see the need for global= attributes but
    > > not for
    > > > >> local ones. What are the use cases that cannot be m= odelled in YANG
    > > now,
    > > > >> e.g. via changing a leaf to a container?
    > > > >>
    > > > >>
    > > > > The global attribute is not that useful.
    > > > > Associating specific metadata with specific data nodes = is more useful.
    > > >
    > > > Metadata associated with specific nodes can be modelled as s= tandard YANG
    > > data
    > > > nodes, perhaps using a grouping.
    > >
    > > But this it what we want to avoid...
    > >
    > > > My serious concern is that people will start using attribute= s as normal
    > > data
    > > > nodes in YANG
    > >
    > > +1
    > >
    > >
    > I did not mention that these attributes are read-only, so it would be<= br> > impossible
    > to replace config leafs with attributes. =A0This abuse you are concern= ed about
    > is not possible.

    This seems like an arbitrary limitation. =A0The "inactive" attrib= ute is
    an example of a read/write (global) attribute. =A0Why would data-node
    specific attributes be read only?

    For both global and local attributes, it must be possible to define
    their read/write properties.

    So what is= supposed to stop someone from defining "netmask" as a
    = global attribute instead of a config leaf? =A0Global vs. local is irrelevan= t,
    except global is worse because the YANG schema does not say
    = the <address> leaf is going to reject any edit that does not include<= /div>
    the 'netmask' attribute.

    Using a= ttributes for editing doesn't work. =A0If you make a CLR that global at= tributes
    can't be "part of the data model", then the same CLR can= be made for local
    attributes.

    =A0
    =



    /martin

    Andy<= /div>

    --047d7b672b440a38f304f841f6c6-- From nobody Wed Apr 30 05:49: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 42C221A081B for ; Wed, 30 Apr 2014 05:49:53 -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_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.651] 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 9Zz5kMU_z5Aa for ; Wed, 30 Apr 2014 05:49:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A96EE1A6F57 for ; Wed, 30 Apr 2014 05:49:51 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 92481140504; Wed, 30 Apr 2014 14:49:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398862189; bh=RgoDeSEyYxBzdvTJn1ID6vFVf0yP6dJxg3jSVE+4yW0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HWx1xKdXEWw2x/wcR36I68nsZ1ZBJ89IVg/ioiK3EOVwkVAqD7Qj9M5AEV+MhIDg8 6p2SVjMN0Ju20ze4EVVAutG05C3uRPNTXQyggOVMeqgr0hjACitghZiTUxGiVFyjUP 8RNnUVcHLgmYVnq4+f+WkCAWOqai/WKAusTOV7hI= 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, 30 Apr 2014 14:49:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA2A59F-54CF-4DC4-A42A-7FB9440A218E@nic.cz> References: <679ABE18-DE2F-4A2F-A3D9-7A1372A3B178@nic.cz> <20140430.100000.412611390.mbj@tail-f.com> <8887FC39-AE73-475F-AB58-E0A04E9ABDBC@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/JK2Xzjg9LdA5kGAtRV5EnWQldoc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 12:49:53 -0000 On 30 Apr 2014, at 11:21, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Apr 30, 2014 at 1:19 AM, Ladislav Lhotka = wrote: >=20 > On 30 Apr 2014, at 10:00, Martin Bjorklund wrote: >=20 > > Ladislav Lhotka wrote: > >>>> Practically speaking, I can see the need for global attributes = but not for > >>>> local ones. What are the use cases that cannot be modelled in = YANG now, > >>>> e.g. via changing a leaf to a container? > >>>> > >>>> > >>> The global attribute is not that useful. > >>> Associating specific metadata with specific data nodes is more = useful. > >> > >> Metadata associated with specific nodes can be modelled as standard = YANG data > >> nodes, perhaps using a grouping. > > > > But this it what we want to avoid=85 >=20 >=20 > this is a strawman. > The solution does not have to be inappropriate or abused. > =20 > What=92s wrong with that? >=20 > data model designers can decide what is appropriate XML attributes were quite often misused, and the schema designers = probably also decided it was appropriate. IMO, that=92s why JSON (so = far) has resisted all attempts to define attributes. > =20 >=20 > > > >> My serious concern is that people will start using attributes as = normal data > >> nodes in YANG > > > > +1 >=20 > people could be designing containers when they should be using leafs. > There are lots of ways one can make bad decisions with YANG. > =20 > > > > I agree with you that having a mechanism to define global meta data = is > > the right way to go. It is quite simple, even if it doesn't solve = all > > use cases as strict as you might like. data node specific meta data > > can be be handled with global meta data, even if it isn't as = elegant. >=20 > I guess it depends on how you define metadata. In a sense, =93inactive=94= or =93nc:operation=94 is more =93meta=94 than say =93language=94 or = =93media-type=94. > =20 >=20 > very good - you picked another attribute that can apply globally. > You are ignoring the 'language string' extension since it clearly does = not apply > to every data node. It is not XML-specific (see the NCX extension). > Adding sibling leafs everywhere there is an admin string is = not practical. Is the role of specified for a text any different from the = role of specified for a network address or route? Where = is the borderline between data and metadata? >=20 > The point of the YANG schema is to let the client know what the server = will implement, > such as which metadata will be returned for which nodes. Metadata can be returned as normal data. Attributes might look more = compact in XML encoding but certainly not in JSON. This would be the = encoding according to draft-ietf-netmod-yang-json-00: "message": "=85", "@message": { "language": "en" }=20 I think the following model is better in that it works for both XML and = JSON: container message { uses lang-string; } and (maybe in another module) grouping lang-string { leaf language { type language-tag; default "en"; } leaf text { type string; } } Lada >=20 > Lada >=20 > > > > > > /martin >=20 >=20 >=20 > Andy > =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 Wed Apr 30 06:03: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 08E351A6F7A for ; Wed, 30 Apr 2014 06:02:57 -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_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.651] 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 DBdtKDfdTf4A for ; Wed, 30 Apr 2014 06:02:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C4C9F1A0816 for ; Wed, 30 Apr 2014 06:02: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 C4F7313F634; Wed, 30 Apr 2014 15:02:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398862974; bh=LrCqj1kZvfkMh+C4MbVQ49L2TNHBL+PYAThSr1/KCx4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PPSUGYaJ+/dOxTZTmZu7bxjCxXxMKx7oq7ErHovGD8fvn13mT55sFaTIqJOJVK/2o 2eslc5saZaoQ3OCpSRqC4gB9wmwKXcFL1dN4PBW1GYThjHC2clObk+zA9vV87CtiLv V3ZgmVcQqLXx+wbhFfTUhe+lmFb73Dqqtib+xgPg= 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, 30 Apr 2014 15:02:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2EF492C8-2634-464E-90E5-BFE29A1C35A9@nic.cz> References: <20140430.100000.412611390.mbj@tail-f.com> <20140430.120437.323948755.mbj@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/R475DALiIu7ydr2blZ9_D0fI5Y8 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 13:02:57 -0000 On 30 Apr 2014, at 14:48, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund = wrote: > Andy Bierman wrote: > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund = wrote: > > > > > Ladislav Lhotka wrote: > > > > >> Practically speaking, I can see the need for global = attributes but > > > not for > > > > >> local ones. What are the use cases that cannot be modelled in = YANG > > > now, > > > > >> e.g. via changing a leaf to a container? > > > > >> > > > > >> > > > > > The global attribute is not that useful. > > > > > Associating specific metadata with specific data nodes is more = useful. > > > > > > > > Metadata associated with specific nodes can be modelled as = standard YANG > > > data > > > > nodes, perhaps using a grouping. > > > > > > But this it what we want to avoid... > > > > > > > My serious concern is that people will start using attributes as = normal > > > data > > > > nodes in YANG > > > > > > +1 > > > > > > > > I did not mention that these attributes are read-only, so it would = be > > impossible > > to replace config leafs with attributes. This abuse you are = concerned about > > is not possible. >=20 > This seems like an arbitrary limitation. The "inactive" attribute is > an example of a read/write (global) attribute. Why would data-node > specific attributes be read only? >=20 > For both global and local attributes, it must be possible to define > their read/write properties. >=20 > So what is supposed to stop someone from defining "netmask" as a > global attribute instead of a config leaf? Global vs. local is = irrelevant, Nothing except it would look extremely stupid. > except global is worse because the YANG schema does not say > the
    leaf is going to reject any edit that does not include > the 'netmask' attribute. >=20 > Using attributes for editing doesn't work. If you make a CLR that = global attributes > can't be "part of the data model", then the same CLR can be made for = local > attributes. The significant difference is that global attributes can be defined = without changing YANG in any way, e. g. via capabilities. I only think = it is more convenient to do it in a YANG module. Local attributes that need to be placed in specific places of the data = tree require making them a new data node type. This IMO already = qualifies as a "fundamentally new data modeling concept=94. Lada >=20 > =20 >=20 >=20 >=20 > /martin >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 30 06:17: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 E82681A08D7 for ; Wed, 30 Apr 2014 06:17:41 -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 EbT8MZd5omKn for ; Wed, 30 Apr 2014 06:17:39 -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 8A2351A0684 for ; Wed, 30 Apr 2014 06:17:39 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id j5so1785632qga.39 for ; Wed, 30 Apr 2014 06:17:38 -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=E5n1BgT3t1R3NNLJll3HS7Rz7gYMvQjBhXWwCpEoBdk=; b=a8LqLEFuixb+xOvFiyjLrWAlwfwD612dvJ7PQRsoCI0faBWknQWQkCZEFXvkEsUVbQ uHk7M6Gs7eVMuRomq4rUvAqlbh4ULWFBwIXoD1Naj3Uses+Ibj67hiHh6SDJPtZlrg8j IxJW8l0E1u9EfFGGOctSzLrVzsgPv/4q3HD4ITnOpEfTYYm/Fj7zNO/84DBBGHD1M3Jz qSOd4R5kUDv7V1tRaHAp0aPNiT5W1nu+XA0NyB7gRC58472fhoayN9+GzfK+2wUzAoSc +x5iLFlrQpLAEzsQdzxe+rBoHduYrek9tyW2/xOU1FFn3+tdvCcNlaiX/rkBMJMPZF1I OU2Q== X-Gm-Message-State: ALoCoQmFTCvxZ0RBNVHch5wdbvJEA8VXvLhP0te6evZr2auKzU66rQtL0QMzB66PUH5h1zivn6r7 MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr5021647qat.78.1398863857876; Wed, 30 Apr 2014 06:17:37 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 06:17:37 -0700 (PDT) In-Reply-To: <2EF492C8-2634-464E-90E5-BFE29A1C35A9@nic.cz> References: <20140430.100000.412611390.mbj@tail-f.com> <20140430.120437.323948755.mbj@tail-f.com> <2EF492C8-2634-464E-90E5-BFE29A1C35A9@nic.cz> Date: Wed, 30 Apr 2014 06:17:37 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b672b445696d804f8425fc9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_sPlhle02JZRGHPDfvQqVdaUwtM Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 13:17:42 -0000 --047d7b672b445696d804f8425fc9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 30, 2014 at 6:02 AM, Ladislav Lhotka wrote: > > On 30 Apr 2014, at 14:48, Andy Bierman wrote: > > > > > > > > > On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund > wrote: > > Andy Bierman wrote: > > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund > wrote: > > > > > > > Ladislav Lhotka wrote: > > > > > >> Practically speaking, I can see the need for global attributes > but > > > > not for > > > > > >> local ones. What are the use cases that cannot be modelled in > YANG > > > > now, > > > > > >> e.g. via changing a leaf to a container? > > > > > >> > > > > > >> > > > > > > The global attribute is not that useful. > > > > > > Associating specific metadata with specific data nodes is more > useful. > > > > > > > > > > Metadata associated with specific nodes can be modelled as > standard YANG > > > > data > > > > > nodes, perhaps using a grouping. > > > > > > > > But this it what we want to avoid... > > > > > > > > > My serious concern is that people will start using attributes as > normal > > > > data > > > > > nodes in YANG > > > > > > > > +1 > > > > > > > > > > > I did not mention that these attributes are read-only, so it would be > > > impossible > > > to replace config leafs with attributes. This abuse you are concerned > about > > > is not possible. > > > > This seems like an arbitrary limitation. The "inactive" attribute is > > an example of a read/write (global) attribute. Why would data-node > > specific attributes be read only? > > > > For both global and local attributes, it must be possible to define > > their read/write properties. > > > > So what is supposed to stop someone from defining "netmask" as a > > global attribute instead of a config leaf? Global vs. local is > irrelevant, > > Nothing except it would look extremely stupid. > ??? so why wouldn't it also be stupid to do as a local attribute? So you would allow 'netmask' as a global attribute, right? But there is no way to indicate which leafs require the attribute to be present. In the general case, any attribute could be considered mandatory to provide with any data node. How does the client know what to send? > > > except global is worse because the YANG schema does not say > > the
    leaf is going to reject any edit that does not include > > the 'netmask' attribute. > > > > Using attributes for editing doesn't work. If you make a CLR that > global attributes > > can't be "part of the data model", then the same CLR can be made for > local > > attributes. > > The significant difference is that global attributes can be defined > without changing YANG in any way, e. g. via capabilities. I only think it > is more convenient to do it in a YANG module. > > Local attributes that need to be placed in specific places of the data > tree require making them a new data node type. This IMO already qualifies > as a "fundamentally new data modeling concept". > ??? Any new statement in YANG is the same here. You cannot add an "attribute-stmt" to YANG 1.1 using a protocol capability. > Lada > > > > > > > > > > > > > /martin > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > Andy --047d7b672b445696d804f8425fc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 30, 2014 at 6:02 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

    On 30 Apr 2014, at 14:48, Andy Bierman <andy@yumaworks.com> wrote:

    >
    >
    >
    > On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
    > Andy Bierman <andy@yumaworks.= com> wrote:
    > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
    > >
    > > > Ladislav Lhotka <lhotka@= nic.cz> wrote:
    > > > > >> Practically speaking, I can see the need for g= lobal attributes but
    > > > not for
    > > > > >> local ones. What are the use cases that cannot= be modelled in YANG
    > > > now,
    > > > > >> e.g. via changing a leaf to a container?
    > > > > >>
    > > > > >>
    > > > > > The global attribute is not that useful.
    > > > > > Associating specific metadata with specific data n= odes is more useful.
    > > > >
    > > > > Metadata associated with specific nodes can be modelled= as standard YANG
    > > > data
    > > > > nodes, perhaps using a grouping.
    > > >
    > > > But this it what we want to avoid...
    > > >
    > > > > My serious concern is that people will start using attr= ibutes as normal
    > > > data
    > > > > nodes in YANG
    > > >
    > > > +1
    > > >
    > > >
    > > I did not mention that these attributes are read-only, so it woul= d be
    > > impossible
    > > to replace config leafs with attributes.  This abuse you are= concerned about
    > > is not possible.
    >
    > This seems like an arbitrary limitation.  The "inactive"= ; attribute is
    > an example of a read/write (global) attribute.  Why would data-no= de
    > specific attributes be read only?
    >
    > For both global and local attributes, it must be possible to define > their read/write properties.
    >
    > So what is supposed to stop someone from defining "netmask" = as a
    > global attribute instead of a config leaf?  Global vs. local is i= rrelevant,

    Nothing except it would look extremely stupid.


    ???

    so why wouldn't it = also be stupid to do as a local attribute?
    So you would allow = 9;netmask' as a global attribute, right?
    But there is no way to indicate which leafs require the attribute to b= e present.

    In the general case, any attribute coul= d be considered mandatory to provide
    with any data node. How does= the client know what to send? 

    > except global is worse because the YANG schema does not say
    > the <address> leaf is going to reject any edit that does not inc= lude
    > the 'netmask' attribute.
    >
    > Using attributes for editing doesn't work.  If you make a CLR= that global attributes
    > can't be "part of the data model", then the same CLR can= be made for local
    > attributes.

    The significant difference is that global attributes can be defined without= changing YANG in any way, e. g. via capabilities. I only think it is more = convenient to do it in a YANG module.

    Local attributes that need to be placed in specific places of the data tree= require making them a new data node type. This IMO already qualifies as a = "fundamentally new data modeling concept”.
    =
    ???
    Any new statement in YANG  is the same here.<= /div>
    You cannot add an "attribute-stmt" to YANG 1.1 using a = protocol capability.


    Lada

    >
    >
    >
    >
    >
    > /martin
    >
    > Andy
    >

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





    Andy
     

    --047d7b672b445696d804f8425fc9-- From nobody Wed Apr 30 07:16: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 DEF791A08F1 for ; Wed, 30 Apr 2014 07:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 5srL9MTWO5lG for ; Wed, 30 Apr 2014 07:16:42 -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 31EF11A08DF for ; Wed, 30 Apr 2014 07:16:42 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id m5so1718964qaj.29 for ; Wed, 30 Apr 2014 07:16:40 -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=F0/xLQSZISdTk2GNsz4W2TbilObSnKINRzXyl9vmF2w=; b=X8yONSh4TITCf9zQkD7K82gTst6rQGwmINf2vbCKwFqYOS59UPwTZ0vZe7vA68xpyk CJ8xXJ5xwk014sQ+WHxQDZOJUG34f4B3lZF1SKnaTCZREruc6QqXo+O96STr1br9wVIR f7ZWGr58/SAC/oGmZHrRKmv0ILE4pOTfe27Qv18+L0GeHmh8zVm3TtZXlZFC2MfCSoCj nydHx6h09xewhgEehkk/45PmTmnLNZhuJgvUkDiR9DtOyLF5TyvHEPgDDXGsY7mh2RIe Sd1Zbzxc+oU/TnAtoI0M5RI/+507TWk7M0wtRhzs0JRbzSxtrnq85qyHjqzqH8dcN9GI P2Lw== X-Gm-Message-State: ALoCoQm4a3CODW1i1d8RuoGeDxtDo26ge2kGTzSQ38QhmcmyrPeVNT7pzTP4l9rzD+5mauUlDyH8 MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr5191399qad.88.1398867400563; Wed, 30 Apr 2014 07:16:40 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 07:16:40 -0700 (PDT) In-Reply-To: <20140430060001.GA29852@elstar.local> References: <20140430060001.GA29852@elstar.local> Date: Wed, 30 Apr 2014 07:16:40 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , feng.chong33@zte.com.cn, "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e0158a9e47fa93304f8433222 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5DFlojhEAuYlKkHUCLVN0yOvx64 Subject: Re: [netmod] YANG1.1 issue:add 'dataset' and 'datastore' statements 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, 30 Apr 2014 14:16:44 -0000 --089e0158a9e47fa93304f8433222 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 29, 2014 at 11:00 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > I think the examples show a misconception about how YANG works and a > likely typical misuse of a mechanism to define 'dataset's and > 'datastores'. I think it would be a mistake to designate say a leaf > definition as belonging to the running datastore instead of marking it > as a config object. > > I do not want YANG modules defining datastores. This classification needs to be hard-wired because the validation rules are specific to the datastore. How does a client know the validation rules for the "acme:special-datastore"? So far, we distinguish configuration objects from operational state > objects. What we are missing seems to be the distinction between > read-only operational state objects and operational state objects that > can be written. I may be very wrong to allow data model writers to > come up with arbitrary such distinctions. > > +1 We have rpc + data nodes + notifications. The 'data nodes' piece consists of a configuration datastore plus some config=false stuff that is not in a configuration datastore. YANG does not define it any further than that. We need to divide the config=false blob into at least 2 pieces: 1) editable operational state 2) non-editable operational state and statistics YANG does not tag data as 'NETCONF' or 'I2RS' but rather just identifies the data properties. The protocol used to edit data is outside the scope of YANG (if it is designed correctly). In other words, a proposal to introduce a mechanism to identify > writable operational state is one thing (if it comes along with a > clear understanding what the impact of this is on the whole > NETCONF/YANG infrastructure). But a proposal to to allow an open ended > set of object classes and datastores seems not very useful. > > /js (speaking as technical contributor) > > Andy > On Wed, Apr 30, 2014 at 09:11:25AM +0800, feng.chong33@zte.com.cn wrote: > > Hi all, > > I suggest add 'dataset' and 'datastore' statements to identify > which > > dataset a data node belongs to. > > YANG use config statement to identify whether the node belongsto > > configuration dataset, but it is not extensible. > > > > For example, I2RS want to define its own dataset, but YANG have no > > syntax to identify which node belongs to I2RS dataset, > > unless I2RS extend its own yang keyword. > > > > I think we should provide a standard way to de this. > > > > 'dataset' statement can be used to define a user-specific dataset. > > and a new statement 'belongs' can be used to identify which dataset > > the data node belongs to, as substatement of data > > nodes(container,list,leaf,leaf-list,anyxml,etc). > > > > 'datastore' statement can be used to define a data store based on > > one dataset. > > > > dataset statement's substatements are listed below: > > > > substatement > > cardinality > > description > > 0..1 > > reference > > 0..1 > > > > datastore statement's substatements are listed below: > > > > substatement > > cardinality > > base > > 1 > > description > > 0..1 > > reference > > 0..1 > > > > The 'base' statement has a argument,its value is a defined dataset, > > to indicate which dataset this datastore is based. > > > > For example: > > dataset config { > > description "the configuration dataset"; > > } > > > > datastore running { > > base config; > > description "running configuration data store"; > > } > > > > dataset i2rs { > > description "i2rs data set"; > > } > > > > datastore i2rs { > > base i2rs; > > } > > > > container foo { > > belongs config; > > list foo-list { > > belongs i2rs; > > key name; > > leaf name {...} > > leaf other {...} > > } > > } > > > > /frank > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this mail > (and any attachment transmitted herewith) is privileged and confidential > and is intended for the exclusive use of the addressee(s). If you are not > an intended recipient, any disclosure, reproduction, distribution or other > dissemination or use of the information contained is strictly prohibited. > If you have received this mail in error, please delete it and notify us > immediately. > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this mail > (and any attachment transmitted herewith) is privileged and confidential > and is intended for the exclusive use of the addressee(s). If you are not > an intended recipient, any disclosure, reproduction, distribution or other > dissemination or use of the information contained is strictly prohibited. > If you have received this mail in error, please delete it and notify us > immediately. > > > _______________________________________________ > > 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 > --089e0158a9e47fa93304f8433222 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 29, 2014 at 11:00 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
    I think the examples show a misconception ab= out how YANG works and a
    likely typical misuse of a mechanism to define 'dataset's and
    'datastores'. I think it would be a mistake to designate say a leaf=
    definition as belonging to the running datastore instead of marking it
    as a config object.


    I do not want YANG modules defining da= tastores.
    This classification needs to be hard-wired because the = validation rules
    are specific to the datastore. How does a client= know the validation
    rules for the "acme:special-datastore"?

    =

    So far, we distinguish configuration objects from operational state
    objects. What we are missing seems to be the distinction between
    read-only operational state objects and operational state objects that
    can be written. I may be very wrong to allow data model writers to
    come up with arbitrary such distinctions.


    +1

    We have rp= c + data nodes + notifications.
    The 'data nodes' piece co= nsists of a configuration datastore
    plus some config=3Dfalse stuf= f that is not in a configuration datastore.
    YANG does not define it any further than that.

    We need to divide the config=3Dfalse blob into at least 2 pieces:
    =A0 1) editable operational state
    =A0 2) non-editable operatio= nal state and statistics

    YANG does not tag data as 'NETCONF' or 'I2R= S' but
    rather just identifies the data properties. =A0The pro= tocol used to
    edit data is outside the scope of YANG (if it is de= signed correctly).



    In other words, a proposal to introduce a mechanism to identify
    writable operational state is one thing (if it comes along with a
    clear understanding what the impact of this is on the whole
    NETCONF/YANG infrastructure). But a proposal to to allow an open ended
    set of object classes and datastores seems not very useful.

    /js (speaking as technical contributor)


    Andy
    =A0
    On Wed, Apr 30, 2014 at 09:11:25AM +0800, feng.chong33@zte.com.cn wrote:
    > Hi all,
    > =A0 =A0 =A0 I suggest add 'dataset' and 'datastore' st= atements to identify which
    > dataset a data node belongs to.
    > =A0 =A0 =A0 YANG use config statement to identify whether the node bel= ongsto
    > configuration dataset, but it is not extensible.
    >
    > =A0 =A0 =A0 For example, I2RS want to define its own dataset, but YANG= have no
    > syntax to identify which node belongs to I2RS dataset,
    > =A0 =A0 =A0 unless I2RS extend its own yang keyword.
    >
    > =A0 =A0 =A0 I think we should provide a standard way to de this.
    >
    > =A0 =A0 =A0 'dataset' statement can be used to define a user-s= pecific dataset.
    > and a new statement 'belongs' can be used to identify which da= taset
    > =A0 =A0 =A0 =A0the data node belongs to, as substatement of data
    > nodes(container,list,leaf,leaf-list,anyxml,etc).
    >
    > =A0 =A0 =A0 'datastore' statement can be used to define a data= store based on
    > one dataset.
    >
    > =A0 =A0 =A0 dataset statement's substatements are listed below: >
    > substatement
    > cardinality
    > description
    > 0..1
    > reference
    > 0..1
    >
    > =A0 =A0 =A0datastore statement's substatements are listed below: >
    > substatement
    > cardinality
    > base
    > 1
    > description
    > 0..1
    > reference
    > 0..1
    >
    > =A0 =A0 =A0The 'base' statement has a argument,its value is a = defined dataset,
    > to indicate which dataset this datastore is based.
    >
    > =A0 =A0 =A0For example:
    > =A0 =A0 =A0dataset config {
    > =A0 =A0 =A0 =A0 description "the configuration dataset";
    > =A0 =A0 =A0}
    >
    > =A0 =A0 =A0datastore running {
    > =A0 =A0 =A0 =A0 base config;
    > =A0 =A0 =A0 =A0 description "running configuration data store&quo= t;;
    > =A0 =A0 =A0}
    >
    > =A0 =A0 =A0dataset i2rs {
    > =A0 =A0 =A0 =A0 =A0description "i2rs data set";
    > =A0 =A0 =A0}
    >
    > =A0 =A0 =A0datastore i2rs {
    > =A0 =A0 =A0 =A0 =A0base i2rs;
    > =A0 =A0 =A0}
    >
    > =A0 =A0 =A0container foo {
    > =A0 =A0 =A0 =A0 belongs config;
    > =A0 =A0 =A0 =A0list foo-list {
    > =A0 =A0 =A0 =A0 =A0 =A0 belongs i2rs;
    > =A0 =A0 =A0 =A0 =A0 =A0 key name;
    > =A0 =A0 =A0 =A0 =A0 =A0 leaf name {...}
    > =A0 =A0 =A0 =A0 =A0 =A0 leaf other {...}
    > =A0 =A0 =A0 =A0}
    > =A0 =A0 =A0}
    >
    > /frank
    > --------------------------------------------------------
    > ZTE Information Security Notice: The information contained in this mai= l (and any attachment transmitted herewith) is privileged and confidential = and is intended for the exclusive use of the addressee(s). =A0If you are no= t an intended recipient, any disclosure, reproduction, distribution or othe= r dissemination or use of the information contained is strictly prohibited.= =A0If you have received this mail in error, please delete it and notify us= immediately.
    > --------------------------------------------------------
    > ZTE Information Security Notice: The information contained in this mai= l (and any attachment transmitted herewith) is privileged and confidential = and is intended for the exclusive use of the addressee(s). =A0If you are no= t an intended recipient, any disclosure, reproduction, distribution or othe= r dissemination or use of the information contained is strictly prohibited.= =A0If you have received this mail in error, please delete it and notify us= immediately.

    > _______________________________________________
    > 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

    --089e0158a9e47fa93304f8433222-- From nobody Wed Apr 30 07:51: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 C6AF21A6FD4 for ; Wed, 30 Apr 2014 07:51:06 -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_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.651] 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 ry9y1DTpjnLr for ; Wed, 30 Apr 2014 07:51:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 027491A6FCB for ; Wed, 30 Apr 2014 07:51:05 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9EFB813F634; Wed, 30 Apr 2014 16:51:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398869462; bh=zQFpbYUWtSqEE85XW9a+IT3Cd+a9BSWQv13sDB+eS74=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DV30XxPsJN5YXY8Nctez2L38M55yhlN7M/iDXlRw3RMRAiq2kvbR9GTibkH7/qdbk QgKOzU2i/fAY+Lm/cL9FgDeeurVuGTzPXoOWky0aNPhENDc4cJs4kEWp0XsHel5yiT GPC2Hw59rH5T38ETjpnwNQKt3DbKSLs7xWuXaS9Y= 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, 30 Apr 2014 16:51:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7567E9E5-66BA-4112-8382-738B52D359A2@nic.cz> References: <20140430.100000.412611390.mbj@tail-f.com> <20140430.120437.323948755.mbj@tail-f.com> <2EF492C8-2634-464E-90E5-BFE29A1C35A9@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/lQLv13hdOD9kb8ui-am-22CfPXs Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 14:51:06 -0000 On 30 Apr 2014, at 15:17, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Apr 30, 2014 at 6:02 AM, Ladislav Lhotka = wrote: >=20 > On 30 Apr 2014, at 14:48, Andy Bierman wrote: >=20 > > > > > > > > On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund = wrote: > > Andy Bierman wrote: > > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund = wrote: > > > > > > > Ladislav Lhotka wrote: > > > > > >> Practically speaking, I can see the need for global = attributes but > > > > not for > > > > > >> local ones. What are the use cases that cannot be modelled = in YANG > > > > now, > > > > > >> e.g. via changing a leaf to a container? > > > > > >> > > > > > >> > > > > > > The global attribute is not that useful. > > > > > > Associating specific metadata with specific data nodes is = more useful. > > > > > > > > > > Metadata associated with specific nodes can be modelled as = standard YANG > > > > data > > > > > nodes, perhaps using a grouping. > > > > > > > > But this it what we want to avoid... > > > > > > > > > My serious concern is that people will start using attributes = as normal > > > > data > > > > > nodes in YANG > > > > > > > > +1 > > > > > > > > > > > I did not mention that these attributes are read-only, so it would = be > > > impossible > > > to replace config leafs with attributes. This abuse you are = concerned about > > > is not possible. > > > > This seems like an arbitrary limitation. The "inactive" attribute = is > > an example of a read/write (global) attribute. Why would data-node > > specific attributes be read only? > > > > For both global and local attributes, it must be possible to define > > their read/write properties. > > > > So what is supposed to stop someone from defining "netmask" as a > > global attribute instead of a config leaf? Global vs. local is = irrelevant, >=20 > Nothing except it would look extremely stupid. >=20 >=20 > ??? >=20 > so why wouldn't it also be stupid to do as a local attribute? > So you would allow 'netmask' as a global attribute, right? No, I would fiercely oppose anything like this becoming part of any = standard. The point is that if attributes become data nodes, people will use and = misuse them as they did in XML. On the other hand, there is no benefit = in defining =93netmask=94 as a global attribute. > But there is no way to indicate which leafs require the attribute to = be present. No, because global attributes convey information that=92s by (my) = definition not part of the data model. If the server indicates support = for disabling any part of the data tree, it doesn=92t mean the = =93inactive=94 attribute becomes part of any data model. The same goes = for the attributes defined in NETCONF. >=20 > In the general case, any attribute could be considered mandatory to = provide > with any data node. How does the client know what to send? This can be again specified without any reference to a data model. It = was possible even before YANG.=20 > =20 >=20 > > except global is worse because the YANG schema does not say > > the
    leaf is going to reject any edit that does not include > > the 'netmask' attribute. > > > > Using attributes for editing doesn't work. If you make a CLR that = global attributes > > can't be "part of the data model", then the same CLR can be made for = local > > attributes. >=20 > The significant difference is that global attributes can be defined = without changing YANG in any way, e. g. via capabilities. I only think = it is more convenient to do it in a YANG module. >=20 > Local attributes that need to be placed in specific places of the data = tree require making them a new data node type. This IMO already = qualifies as a "fundamentally new data modeling concept=94. >=20 > ??? > Any new statement in YANG is the same here. > You cannot add an "attribute-stmt" to YANG 1.1 using a protocol = capability. No, but I can use a protocol capability for defining a new global = attribute with specific semantics that will work even with YANG 1.0 - = that=92s why it cannot be considered a new data modeling concept. The advantage of having a new =93attribute=94 statement in YANG is that - the attribute will automatically get a namespace and recommended = prefix, - the namespace encoding is also readily defined in JSON, - it can possibly be assigned a datatype, - descriptions, references etc. can be used for specifying the = attribute=92s semantics. Lada=20 >=20 >=20 > Lada >=20 > > > > > > > > > > > > /martin > > > > Andy > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 > Andy > =20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 30 08:14: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 5E4F61A6FD3 for ; Wed, 30 Apr 2014 08:14: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 U7DoHDkR9Cob for ; Wed, 30 Apr 2014 08:14:33 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5911A6FDE for ; Wed, 30 Apr 2014 08:14:33 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so1962201qgd.19 for ; Wed, 30 Apr 2014 08:14: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=fibsFzQlR1aFfZc/fl/rolCfLYiVgUXnyef2wyVgTFY=; b=GCiMS1EcLxAs6UJQpVLvgtQoj0+Az5jZARK1Xnu7p+l7kG3dWD1FRs1QzYXypBqmAL GZM3CKyxCpiDDCWgfPvUuZ9hn5svYZE92Q64Zv7tmVtgL+TogYWCfNCsoC47E3L/GWbL KW1u0ywzXY1IVkdct/XEromSon8NzYSU7wiFOQnihuh147eN04R6CpvfFyjvfTuB7+iy 8Lwds5gDO+MHLxHq/kDZgjzBR/6ibjveMxoCI+zkaHluSNeRX4WcsZbMIMTsANvvsRuy T/odjQc0yEkzcAHTcDwFpS/1vIE5ld9vCoJ5CnTKeorTkdlMzbm6arnQKQdUyBM5UOZv DMkA== X-Gm-Message-State: ALoCoQlGumQh3/3HqiJE1+qP7uKMGE4jCGI3ZwkK4blpr1g6fytaNV/cX4TQd5BhPyhEqpaHmsuf MIME-Version: 1.0 X-Received: by 10.229.17.69 with SMTP id r5mr6166858qca.7.1398870871300; Wed, 30 Apr 2014 08:14:31 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 08:14:31 -0700 (PDT) In-Reply-To: <7567E9E5-66BA-4112-8382-738B52D359A2@nic.cz> References: <20140430.100000.412611390.mbj@tail-f.com> <20140430.120437.323948755.mbj@tail-f.com> <2EF492C8-2634-464E-90E5-BFE29A1C35A9@nic.cz> <7567E9E5-66BA-4112-8382-738B52D359A2@nic.cz> Date: Wed, 30 Apr 2014 08:14:31 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1133c9385ef20e04f84401f7 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/e0GHJoD9wtrFmQ8gT-CWqNbmWQk Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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, 30 Apr 2014 15:14:36 -0000 --001a1133c9385ef20e04f84401f7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 30, 2014 at 7:51 AM, Ladislav Lhotka wrote: > > On 30 Apr 2014, at 15:17, Andy Bierman wrote: > > > > > > > > > On Wed, Apr 30, 2014 at 6:02 AM, Ladislav Lhotka wrote: > > > > On 30 Apr 2014, at 14:48, Andy Bierman wrote: > > > > > > > > > > > > > > On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund > wrote: > > > Andy Bierman wrote: > > > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund > wrote: > > > > > > > > > Ladislav Lhotka wrote: > > > > > > >> Practically speaking, I can see the need for global > attributes but > > > > > not for > > > > > > >> local ones. What are the use cases that cannot be modelled in > YANG > > > > > now, > > > > > > >> e.g. via changing a leaf to a container? > > > > > > >> > > > > > > >> > > > > > > > The global attribute is not that useful. > > > > > > > Associating specific metadata with specific data nodes is more > useful. > > > > > > > > > > > > Metadata associated with specific nodes can be modelled as > standard YANG > > > > > data > > > > > > nodes, perhaps using a grouping. > > > > > > > > > > But this it what we want to avoid... > > > > > > > > > > > My serious concern is that people will start using attributes as > normal > > > > > data > > > > > > nodes in YANG > > > > > > > > > > +1 > > > > > > > > > > > > > > I did not mention that these attributes are read-only, so it would be > > > > impossible > > > > to replace config leafs with attributes. This abuse you are > concerned about > > > > is not possible. > > > > > > This seems like an arbitrary limitation. The "inactive" attribute is > > > an example of a read/write (global) attribute. Why would data-node > > > specific attributes be read only? > > > > > > For both global and local attributes, it must be possible to define > > > their read/write properties. > > > > > > So what is supposed to stop someone from defining "netmask" as a > > > global attribute instead of a config leaf? Global vs. local is > irrelevant, > > > > Nothing except it would look extremely stupid. > > > > > > ??? > > > > so why wouldn't it also be stupid to do as a local attribute? > > So you would allow 'netmask' as a global attribute, right? > > No, I would fiercely oppose anything like this becoming part of any > standard. > > The point is that if attributes become data nodes, people will use and > misuse them as they did in XML. On the other hand, there is no benefit in > defining "netmask" as a global attribute. > > I agree on that point. I do not want data model properties defined in attributes. But you missed my point -- if we can define these rules for global attributes, we obviously can define them for local attributes as well. > > > But there is no way to indicate which leafs require the attribute to be > present. > > No, because global attributes convey information that's by (my) definition > not part of the data model. If the server indicates support for disabling > any part of the data tree, it doesn't mean the "inactive" attribute becomes > part of any data model. The same goes for the attributes defined in NETCONF. > > 1) there is really no way for the YANG compiler to tell the difference between an attribute for "enabled" vs. an attribute for "netmask". 2) global attributes that only apply to a subset of nodes are needed, such as the language of an administrative string. Here is a solution to demonstrate that we are actually in agreement:: - there are only global attributes, which are not allowed to contain data model properties. The attribute will define if it is read-write/read-only, etc. - there is also a sub-statement to use specific attributes. attribute language { description "Identifies the language for the associated string data type. as defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]." } leaf admin-string { type string; uses-attribute foo:language; } > > > In the general case, any attribute could be considered mandatory to > provide > > with any data node. How does the client know what to send? > > This can be again specified without any reference to a data model. It was > possible even before YANG. > > > > > > > except global is worse because the YANG schema does not say > > > the
    leaf is going to reject any edit that does not include > > > the 'netmask' attribute. > > > > > > Using attributes for editing doesn't work. If you make a CLR that > global attributes > > > can't be "part of the data model", then the same CLR can be made for > local > > > attributes. > > > > The significant difference is that global attributes can be defined > without changing YANG in any way, e. g. via capabilities. I only think it > is more convenient to do it in a YANG module. > > > > Local attributes that need to be placed in specific places of the data > tree require making them a new data node type. This IMO already qualifies > as a "fundamentally new data modeling concept". > > > > ??? > > Any new statement in YANG is the same here. > > You cannot add an "attribute-stmt" to YANG 1.1 using a protocol > capability. > > No, but I can use a protocol capability for defining a new global > attribute with specific semantics that will work even with YANG 1.0 - > that's why it cannot be considered a new data modeling concept. > > this is what we have today > The advantage of having a new "attribute" statement in YANG is that > > - the attribute will automatically get a namespace and recommended prefix, > > - the namespace encoding is also readily defined in JSON, > > - it can possibly be assigned a datatype, > > - descriptions, references etc. can be used for specifying the attribute's > semantics. > > So some attributes will be defined in the protocol and accessible via XML only, and some will be defined in YANG, so they can be accessed in XML and JSON. Isn't that a problem? How will protocol defined attributes be supported in JSON? Lada > > Andy > > > > > > Lada > > > > > > > > > > > > > > > > > > > > /martin > > > > > > Andy > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > Andy > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1133c9385ef20e04f84401f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Wed, Apr 30, 2014 at 7:51 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

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

    >
    >
    >
    > On Wed, Apr 30, 2014 at 6:02 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
    >
    > On 30 Apr 2014, at 14:48, Andy Bierman <andy@yumaworks.com> wrote:
    >
    > >
    > >
    > >
    > > On Wed, Apr 30, 2014 at 3:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
    > > Andy Bierman <andy@yumaw= orks.com> wrote:
    > > > On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
    > > >
    > > > > Ladislav Lhotka <lh= otka@nic.cz> wrote:
    > > > > > >> Practically speaking, I can see the need = for global attributes but
    > > > > not for
    > > > > > >> local ones. What are the use cases that c= annot be modelled in YANG
    > > > > now,
    > > > > > >> e.g. via changing a leaf to a container?<= br> > > > > > >>
    > > > > > >>
    > > > > > > The global attribute is not that useful.
    > > > > > > Associating specific metadata with specific d= ata nodes is more useful.
    > > > > >
    > > > > > Metadata associated with specific nodes can be mod= elled as standard YANG
    > > > > data
    > > > > > nodes, perhaps using a grouping.
    > > > >
    > > > > But this it what we want to avoid...
    > > > >
    > > > > > My serious concern is that people will start using= attributes as normal
    > > > > data
    > > > > > nodes in YANG
    > > > >
    > > > > +1
    > > > >
    > > > >
    > > > I did not mention that these attributes are read-only, so it= would be
    > > > impossible
    > > > to replace config leafs with attributes.  This abuse yo= u are concerned about
    > > > is not possible.
    > >
    > > This seems like an arbitrary limitation.  The "inactive= " attribute is
    > > an example of a read/write (global) attribute.  Why would da= ta-node
    > > specific attributes be read only?
    > >
    > > For both global and local attributes, it must be possible to defi= ne
    > > their read/write properties.
    > >
    > > So what is supposed to stop someone from defining "netmask&q= uot; as a
    > > global attribute instead of a config leaf?  Global vs. local= is irrelevant,
    >
    > Nothing except it would look extremely stupid.
    >
    >
    > ???
    >
    > so why wouldn't it also be stupid to do as a local attribute?
    > So you would allow 'netmask' as a global attribute, right?

    No, I would fiercely oppose anything like this becoming part of any standar= d.

    The point is that if attributes become data nodes, people will use and misu= se them as they did in XML. On the other hand, there is no benefit in defin= ing “netmask” as a global attribute.



    I agree on that point. =  I do not want data model properties defined
    in attributes.<= /div>

    But you missed my point -- if we can define these = rules for global
    attributes, we obviously can define them for local attributes as well.=

     

    > But there is no way to indicate which leafs require the attribute to b= e present.

    No, because global attributes convey information that’s by (my) defin= ition not part of the data model. If the server indicates support for disab= ling any part of the data tree, it doesn’t mean the “inactive&r= dquo; attribute becomes part of any data model. The same goes for the attri= butes defined in NETCONF.



    1) there is really no w= ay for the YANG compiler to tell the difference between
    an attrib= ute for "enabled" vs. an attribute for "netmask".

    2) global attributes that only apply to a subset of nod= es are needed, such
       as the language of an administra= tive string.

    Here is a solution to demonstrate tha= t we are actually in agreement::

     - there are only global attributes, which are not= allowed to contain data model
       properties.  The= attribute will define if it is read-write/read-only, etc.

     - there is also a sub-statement to use specific attributes.<= /div>

    attribute language {
       description=
         "Identifies the language for the associ= ated string data type.
          as defined in [W3C.REC-xml= -20001006] and discussed in [RFC3470]."
     }


     lea= f admin-string {
       type string;<= br>
       uses-attribute foo:language;
    &= nbsp;}


    >
    > In the general case, any attribute could be considered mandatory to pr= ovide
    > with any data node. How does the client know what to send?

    This can be again specified without any reference to a data model. It was p= ossible even before YANG.
    >
    >
    > > except global is worse because the YANG schema does not say
    > > the <address> leaf is going to reject any edit that does no= t include
    > > the 'netmask' attribute.
    > >
    > > Using attributes for editing doesn't work.  If you make = a CLR that global attributes
    > > can't be "part of the data model", then the same CL= R can be made for local
    > > attributes.
    >
    > The significant difference is that global attributes can be defined wi= thout changing YANG in any way, e. g. via capabilities. I only think it is = more convenient to do it in a YANG module.
    >
    > Local attributes that need to be placed in specific places of the data= tree require making them a new data node type. This IMO already qualifies = as a "fundamentally new data modeling concept”.
    >
    > ???
    > Any new statement in YANG  is the same here.
    > You cannot add an "attribute-stmt" to YANG 1.1 using a proto= col capability.

    No, but I can use a protocol capability for defining a new global attribute= with specific semantics that will work even with YANG 1.0 - that’s w= hy it cannot be considered a new data modeling concept.


    this is what we have today
    &= nbsp;
    The advantage of having a new “attribute” statement in YANG is = that

    - the attribute will automatically get a namespace and recommended prefix,<= br>
    - the namespace encoding is also readily defined in JSON,

    - it can possibly be assigned a datatype,

    - descriptions, references etc. can be used for specifying the attribute&rs= quo;s semantics.


    So some attributes will be defined in = the protocol and accessible via XML only,
    and some will be define= d in YANG, so they can be accessed in XML and JSON. 
    Isn'= ;t that a problem? How will protocol defined attributes be supported in JSO= N?


    Lada


    Andy

     
    >
    >
    > Lada
    >
    > >
    > >
    > >
    > >
    > >
    > > /martin
    > >
    > > Andy
    > >
    >
    > --
    > Ladislav Lhotka, CZ.NIC Labs
    > PGP Key ID: E74E8C0C
    >
    >
    >
    >
    >
    > Andy
    >
    >

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





    --001a1133c9385ef20e04f84401f7-- From nobody Wed Apr 30 09:54: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 ECBC01A8824 for ; Wed, 30 Apr 2014 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] 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 Vui0rNJsHMaN for ; Wed, 30 Apr 2014 09:32:56 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) by ietfa.amsl.com (Postfix) with ESMTP id E49981A8839 for ; Wed, 30 Apr 2014 09:32:55 -0700 (PDT) Received: from [192.168.1.132] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s3UGWpR6024221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 12:32:52 -0400 (EDT) Message-ID: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Niels =?ISO-8859-1?Q?M=F6ller?= Date: Wed, 30 Apr 2014 12:32:50 -0400 In-Reply-To: References: <20140429.220505.221212226.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cSNO0ThQkIUhvsLqDU8C80Qno78 X-Mailman-Approved-At: Wed, 30 Apr 2014 09:54:04 -0700 Cc: ietf-ssh@NetBSD.org, netmod@ietf.org, jhutz@cmu.edu Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt 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, 30 Apr 2014 16:33:02 -0000 On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > However, if we also keep the leaf algorithm, we need to specify > > what happens if the leaf algorithm has a value that is different > > from the value embedded in the key blob. > > Right, eliminating this redundancy makes things simpler. It would, except you can't eliminate it. The second copy of the algorithm name is part of the key data format for _certain public key algorithms_, but not necessarily for all of them. The right thing here is to leave it as defined - the "algorithm" is a string naming the public key algorithm, and the "key-data" is an _opaque_ base64 blob. The fact that for certain kinds of keys the opaque blob happens to contain a copy of the algorithm name is irrelevant. As for what happens when they're different -- it doesn't work! If you say you're providing a key for one algorithm and actually provide key data for a different one, it's simply not going to work. You could check when setting a key that the provided key data is valid for the specified algorithm, but I would very strongly recommend against that. Doing so requires that whatever's doing the validation understand all possible key algorithms, which is impossible, since public key algorithm names are a vendor-extensible namespace. > I think it would make more sense to have a name that reflects the > *purpose* of the list of keys, rather than just the data type. E.g., if > it's authorization keys for logging in to the users account, it could be > "authorized-ssh-keys" or something like that. Yes. From nobody Wed Apr 30 10:04:52 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 818341A7034 for ; Wed, 30 Apr 2014 10:04:48 -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 Fd6-HkA_L8lI for ; Wed, 30 Apr 2014 10:04:43 -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 C85181A0910 for ; Wed, 30 Apr 2014 10:04:42 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id j7so1933864qaq.34 for ; Wed, 30 Apr 2014 10:04:41 -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=mrmnJKxbi61ZLe/nQWI4rcMHFpABHRfX0pjGsNJm9bI=; b=f2QT+TQfU0Qe9Y/erV0TwEUd+cKcdzNZbs5tVyku+N8vYwbsz0wqVb16mZMa1Lbz6q 66HsYdEKml7DZhqWx0m+/K9nZtqB1Xr2U2txGcVsZqfTyxAAesB+y8hrl+usPVAfh0Cg rdUqftYkAwfDHwJGvt9yZGiFuS6W68fSHQ0ArE9BbLg+MDzGrf7lZwuQshyRgmeKaHPr BpmL5+wCyIT00Mh2rWLufe3QRvLY18jE0DHuMkj9/3m4bT8BGs9JGF0DJt5z0hMjakPA TaSIycnXTSWZelznDh0uMOt3rL37SGa4549hLegJ2lO48iebbx9vN2SI8/OvZ5OAGXQ5 JhXw== X-Gm-Message-State: ALoCoQnT9E9dP2GBMXP09w13yOfm99nx5c+dxc+rMg2HqWuHBQQNNUyt7iUDvdDXzh3LmnFoefC6 MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr6410073qad.88.1398877480942; Wed, 30 Apr 2014 10:04:40 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 10:04:40 -0700 (PDT) In-Reply-To: References: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 10:04:40 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0158a9e456187c04f8458b0c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JqIyWrbU5XNIUTqVdPSu7wI64Ng Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.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: Wed, 30 Apr 2014 17:04:48 -0000 --089e0158a9e456187c04f8458b0c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 29, 2014 at 6:23 PM, Kent Watsen wrote: > > I noticed this draft up for Last Call again and yet the issues raised her= e > haven=B9t been addressed yet: > > http://www.ietf.org/mail-archive/web/netconf/current/msg08848.htm= l > > Now I see that we have another go at a Last Call for this draft, can we > please fix these issue this time? It doesn=B9t make sense to have these > things configured in the netconf-server-model draft... > > Can you provide an OLD vs NEW style text change proposal that shows what will change in the system draft? > Thanks, > Kent > > Andy > > > On 4/29/14, 3:17 AM, "internet-drafts@ietf.org" > wrote: > > > > >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-15.txt > > Pages : 40 > > Date : 2014-04-29 > > > >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-15 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-15 > > > > > >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/ > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0158a9e456187c04f8458b0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Apr 29, 2014 at 6:23 PM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:

    I noticed this draft up for Last Call again and yet the issues raised here<= br> haven=B9t been addressed yet:

    =A0 =A0 =A0 =A0 http://www.ietf.org/mail-archive/web/= netconf/current/msg08848.html

    Now I see that we have another go at a Last Call for this draft, can we
    please fix these issue this time? =A0It doesn=B9t make sense to have these<= br> things configured in the netconf-server-model draft...


    Can you provide an OLD vs NEW style te= xt change proposal that shows what will
    change in the system draf= t?

    =A0
    Thanks,
    Kent


    Andy
    =A0


    On 4/29/14, 3:17 AM, "inte= rnet-drafts@ietf.org" <internet-drafts@ietf.org>
    wrote:

    >
    >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 Workin= g
    >Group of the IETF.
    >
    > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A YANG Data Model for Syste= m Management
    > =A0 =A0 =A0 =A0Authors =A0 =A0 =A0 =A0 : Andy Bierman
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Martin Bjorklund > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-netmod-system-mgmt-15= .txt
    > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 40
    > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-04-29
    >
    >Abstract:
    > =A0 This document defines a YANG data model for the configuration and<= br> > =A0 identification of some common system properties within a device > =A0 containing a NETCONF server. =A0This includes data node definition= s for
    > =A0 system identification, time-of-day management, user management, DN= S
    > =A0 resolver configuration, and some protocol operations for system > =A0 management.
    >
    >
    >The IETF datatracker status page for this draft is:
    >https://datatracker.ietf.org/doc/draft-ietf-netmod-s= ystem-mgmt/
    >
    >There's also a htmlized version available at:
    >http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt= -15
    >
    >A diff from the previous version is available at:
    >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ne= tmod-system-mgmt-15
    >
    >
    >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/
    >
    >_______________________________________________
    >netmod mailing list
    >netmod@ietf.org
    >https://www.ietf.org/mailman/listinfo/netmod

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

    --089e0158a9e456187c04f8458b0c-- From nobody Wed Apr 30 10:50: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 159B91A8838 for ; Wed, 30 Apr 2014 10:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 x0wiiQSi3O5c for ; Wed, 30 Apr 2014 10:50:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1331A70E1 for ; Wed, 30 Apr 2014 10:50:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 728FB10B3; Wed, 30 Apr 2014 19:50:34 +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 3VhCXqX4eqPy; Wed, 30 Apr 2014 19:50:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 19:50:33 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBC8820017; Wed, 30 Apr 2014 19:50:33 +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 TDJ6NsIFH4h6; Wed, 30 Apr 2014 19:50:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9176C20013; Wed, 30 Apr 2014 19:50:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CE4802CC6EFB; Wed, 30 Apr 2014 19:50:31 +0200 (CEST) Date: Wed, 30 Apr 2014 19:50:31 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20140430175031.GC31746@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , Niels =?iso-8859-1?Q?M=F6ller?= , Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YQhWjMFaa7Vo0OmOtDbIwV_7TZo Cc: ietf-ssh@NetBSD.org, Niels =?iso-8859-1?Q?M=F6ller?= , netmod@ietf.org Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt 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: Wed, 30 Apr 2014 17:50:38 -0000 On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote: > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > > However, if we also keep the leaf algorithm, we need to specify > > > what happens if the leaf algorithm has a value that is different > > > from the value embedded in the key blob. > > > > Right, eliminating this redundancy makes things simpler. > > It would, except you can't eliminate it. The second copy of the > algorithm name is part of the key data format for _certain public key > algorithms_, but not necessarily for all of them. > Hm. Are you saying RFC 4716 is broken or only applicable to certain subset of public key algorithms? In which case would the public key not follow [RFC4253], Section 6.6: string certificate or public key format identifier byte[n] key/certificate data I am just trying to understand this. /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 Wed Apr 30 11:14:27 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 EEEE51A091A for ; Wed, 30 Apr 2014 11:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 fhAD_vREkqEO for ; Wed, 30 Apr 2014 11:14:24 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id 701A61A04B6 for ; Wed, 30 Apr 2014 11:14:24 -0700 (PDT) Received: from [192.168.1.132] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s3UIEKn9024313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 14:14:21 -0400 (EDT) Message-ID: <1398881659.20380.39.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Juergen Schoenwaelder Date: Wed, 30 Apr 2014 14:14:19 -0400 In-Reply-To: <20140430175031.GC31746@elstar.local> References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <20140430175031.GC31746@elstar.local> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SD0bAtTGhrVinyIoeGBQWE2JHlI Cc: ietf-ssh@NetBSD.org, Niels =?ISO-8859-1?Q?M=F6ller?= , netmod@ietf.org, jhutz@cmu.edu Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt 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, 30 Apr 2014 18:14:26 -0000 On Wed, 2014-04-30 at 19:50 +0200, Juergen Schoenwaelder wrote: > On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote: > > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > > > However, if we also keep the leaf algorithm, we need to specify > > > > what happens if the leaf algorithm has a value that is different > > > > from the value embedded in the key blob. > > > > > > Right, eliminating this redundancy makes things simpler. > > > > It would, except you can't eliminate it. The second copy of the > > algorithm name is part of the key data format for _certain public key > > algorithms_, but not necessarily for all of them. > > > > Hm. Are you saying RFC 4716 is broken or only applicable to certain > subset of public key algorithms? In which case would the public key > not follow [RFC4253], Section 6.6: > > string certificate or public key format identifier > byte[n] key/certificate data > > I am just trying to understand this. Section 6.6 is actually quite specific on this: The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. It then goes on to define two key types ("ssh-dss" and "ssh-rsa") which each begin with a fixed string that is the same as the key type name, and two more which are unfortunately rather vague, but which I don't think are commonly used. I seem to recall this being an issue in the past, because someone made an assumption that keys would always be self-describing when in fact they were not. Unfortunately, I no longer remember the exact circumstances. But yes, I believe RFC4716 is broken, because it relies on the encoding described above, rather than being consistent with the requirement "The key type MUST always be explicitly known." IMHO, things that are not implementations of SSH should not need to be aware of SSH's encoding or of the details of particular public key formats. They should treat the opaque key data as opaque, and separate from the key type. -- Jeff From nobody Wed Apr 30 12: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 96AE21A064D for ; Wed, 30 Apr 2014 12:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 uZa_3KoH0JUR for ; Wed, 30 Apr 2014 12:20:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AF39C1A886B for ; Wed, 30 Apr 2014 12:20:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E0C35FED; Wed, 30 Apr 2014 21:20: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 y2XWrsnN-GZl; Wed, 30 Apr 2014 21:20:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 21:20:04 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0571220017; Wed, 30 Apr 2014 21:20:04 +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 zXrI6nTGUqmj; Wed, 30 Apr 2014 21:20:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1E9A20013; Wed, 30 Apr 2014 21:20:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 238402CC6F9A; Wed, 30 Apr 2014 21:20:00 +0200 (CEST) Date: Wed, 30 Apr 2014 21:20:00 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20140430192000.GA31986@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , Niels =?iso-8859-1?Q?M=F6ller?= , Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <20140430175031.GC31746@elstar.local> <1398881659.20380.39.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1398881659.20380.39.camel@destiny.pc.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/95Qt_ghJ4cpjEzFj2oE93T39zo8 Cc: ietf-ssh@NetBSD.org, Niels =?iso-8859-1?Q?M=F6ller?= , netmod@ietf.org Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt 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: Wed, 30 Apr 2014 19:20:16 -0000 On Wed, Apr 30, 2014 at 02:14:19PM -0400, Jeffrey Hutzelman wrote: > On Wed, 2014-04-30 at 19:50 +0200, Juergen Schoenwaelder wrote: > > On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote: > > > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > > > > However, if we also keep the leaf algorithm, we need to specify > > > > > what happens if the leaf algorithm has a value that is different > > > > > from the value embedded in the key blob. > > > > > > > > Right, eliminating this redundancy makes things simpler. > > > > > > It would, except you can't eliminate it. The second copy of the > > > algorithm name is part of the key data format for _certain public key > > > algorithms_, but not necessarily for all of them. > > > > > > > Hm. Are you saying RFC 4716 is broken or only applicable to certain > > subset of public key algorithms? In which case would the public key > > not follow [RFC4253], Section 6.6: > > > > string certificate or public key format identifier > > byte[n] key/certificate data > > > > I am just trying to understand this. > > Section 6.6 is actually quite specific on this: > > The key type MUST always be explicitly known (from algorithm > negotiation or some other source). It is not normally included in > the key blob. > > > It then goes on to define two key types ("ssh-dss" and "ssh-rsa") which > each begin with a fixed string that is the same as the key type name, > and two more which are unfortunately rather vague, but which I don't > think are commonly used. Well, but the text in section 6.6 also says this (right after the text you quoted): : Certificates and public keys are encoded as follows: : : string certificate or public key format identifier : byte[n] key/certificate data This text does not look conditional and perhaps this is where the confusion comes from? For me, as a reader who has no prior involvement in this, these two paragraphs look a bit like a contradiction... > I seem to recall this being an issue in the past, because someone made > an assumption that keys would always be self-describing when in fact > they were not. Unfortunately, I no longer remember the exact > circumstances. But yes, I believe RFC4716 is broken, because it relies > on the encoding described above, rather than being consistent with the > requirement "The key type MUST always be explicitly known." OK. I am happy to follow you advice to keep the algorithm type leaf. > IMHO, things that are not implementations of SSH should not need to be > aware of SSH's encoding or of the details of particular public key > formats. They should treat the opaque key data as opaque, and separate > from the key type. Yes, I think we agree. I do not expect a NETCONF server to try to validate whether the key blob is valid. /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 Wed Apr 30 12:50: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 0243A1A0972 for ; Wed, 30 Apr 2014 12:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 1fQkZaWg24wN for ; Wed, 30 Apr 2014 12:49:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 578121A095F for ; Wed, 30 Apr 2014 12:49:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 88607FAB; Wed, 30 Apr 2014 21:49:53 +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 brBkkEq6BLoc; Wed, 30 Apr 2014 21:49:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 21:49:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C35020017; Wed, 30 Apr 2014 21:49:52 +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 xklX__jPKtPV; Wed, 30 Apr 2014 21:49:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D51220013; Wed, 30 Apr 2014 21:49:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 41F2B2CC704D; Wed, 30 Apr 2014 21:49:51 +0200 (CEST) Date: Wed, 30 Apr 2014 21:49:51 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140430194951.GC31986@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kjcDSAElOTLeVfH-7RVSk9QcKdY Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt 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: Wed, 30 Apr 2014 19:50:03 -0000 On Wed, Apr 30, 2014 at 01:23:16AM +0000, Kent Watsen wrote: > > I noticed this draft up for Last Call again and yet the issues raised here > haven¹t been addressed yet: > > http://www.ietf.org/mail-archive/web/netconf/current/msg08848.html > > Now I see that we have another go at a Last Call for this draft, can we > please fix these issue this time? It doesn¹t make sense to have these > things configured in the netconf-server-model draft... > Kent, the process is somewhat like this (a bit simplified): a) WG works on a document does WG last calls to determine the WG is done an happy with the result b) Work is submitted to the IESG and the responsible AD initiates an IETF last call to check that the larger IETF community is fine with the result produced by the WG c) The IESG members review the documents (and the IETF last call comments) and IESG members can raise DISCUSSes that require to discuss whether there is an issue preventing the publication of the document The main reason why we have a second IETF last call is the fact that we have a normative reference to a document that is not on the standards track and this was not properly spelled out in the first IETF last call - so we are essentially fixing a procedural error. Of course, since there is another IETF last call, you can raise an issue during this second IETF last call if you believe the document is not ready. So much about the process. Taking the process aside, we did receive several comments of the form "why does the data model not also cover XYZ" during the IESG review phase and we consistently answered that trying to cover everything means we will never finish this data model and that we (the chairs) believe the current scope has WG consensus and that it is time to get this published, implemented, and deployed. We do expect revisions and / or extensions of the data model based on experience we gain. You can find the history of this document here: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/history/ It took us about two years from the WG -00 version to IESG submission and almost three years from Andy's original I-D. I am strongly in favour of publishing what we have. Note that it is possible both to revise data models and to augment them and we kind of expect this to happen with the core system data model. So keep this in mind when you think about the issue. Are we having an issue that renders the current version unusable or is this just one of the many additions one can imagine but which may as well go into a future revision or augmentation of the data model? In the later case, I prefer to not pull this document out of the IESG back into the WG. /js PS: Note that it took 8 months from the initial submission of an individual I-D for the RFC 6021 revision to IESG approval (with 4 months since WG -00 version). It is well possible to revise a data model within a year should there be a need. PS: I personally do not believe that the user authentation objects in the sytem draft need configuration of certifications and trust anchors. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Apr 30 13:06: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 519B61A097D for ; Wed, 30 Apr 2014 13:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] 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 Wcy7MsimEx_9 for ; Wed, 30 Apr 2014 13:06:24 -0700 (PDT) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8541A0972 for ; Wed, 30 Apr 2014 13:06:21 -0700 (PDT) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s3UK68KY009766; Wed, 30 Apr 2014 22:06:08 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s3UK66oK009765; Wed, 30 Apr 2014 22:06:06 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Jeffrey Hutzelman References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> Date: Wed, 30 Apr 2014 22:06:06 +0200 In-Reply-To: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 30 Apr 2014 12:32:50 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VnecKuSbfFx8B7-t1hipMv5vaLw Cc: ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt 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, 30 Apr 2014 20:06:26 -0000 Jeffrey Hutzelman writes: > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: >> > However, if we also keep the leaf algorithm, we need to specify >> > what happens if the leaf algorithm has a value that is different >> > from the value embedded in the key blob. >> >> Right, eliminating this redundancy makes things simpler. > > It would, except you can't eliminate it. Hmm. I think you're right. So then then the "algorithm" leaf would be the name being used in algorithm negotiation and the like, and the "key" leaf would be the key blob. The key blob typically starts with a string containing the algorithm identifier, but nothing but the ssh implementation is expected to care about that detail. So then the right choice is 1), : 1) Clarify that the leaf "key-data" contains: : : string certificate or public key format identifier : byte[n] key/certificate data : : This allows for simple copy-and-paste from normal open ssh and : rfc4716 files. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Wed Apr 30 17:38:52 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 8619C1A802D for ; Wed, 30 Apr 2014 17:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D4RviB0-JW5m for ; Wed, 30 Apr 2014 17:38:47 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B55C1A6FFE for ; Wed, 30 Apr 2014 17:38:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=stsD3iZ8mvqcRQ7xrTy16379UcioISuCXaH4ArnKnSFdEUqxvANmrce+i/kaiN9I; 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-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Wff1J-00066u-Qx for netmod@ietf.org; Wed, 30 Apr 2014 20:38:37 -0400 Received: from 99.23.160.68 by webmail.earthlink.net with HTTP; Wed, 30 Apr 2014 20:38:37 -0400 Message-ID: <26077529.1398904717605.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Wed, 30 Apr 2014 17:38:37 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc6f642e2633482c7eb3797d5cf9ea5ad9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/s1CFyJEgkLkfU6RGMVrkr9t8HEs Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes 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: Thu, 01 May 2014 00:38:49 -0000 Hi - >From: Ladislav Lhotka >Sent: Apr 30, 2014 5:49 AM >To: Andy Bierman >Cc: "netmod@ietf.org" >Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes ... >Is the role of specified for a text any different >from the role of specified for a network >address or route? Perhaps not in kind, but certainly in degree. >Where is the borderline between data and >metadata? If I have a "content analysis" field with a value of "Gift", I really do need to know whether the language is English or German. To me, the value of the language tag is data. The fact that there may be a language tag, any constrains on the set on possible language tags, and any additional semantics attached to the presence or absence of language tags, would be in the realm of metadata. Randy From nobody Wed Apr 30 21:18: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 BE6B01A084D for ; Wed, 30 Apr 2014 21:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 rk_23qIZxdAS for ; Wed, 30 Apr 2014 21:18:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id 5A12C1A0730 for ; Wed, 30 Apr 2014 21:18:38 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 04:18:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.186]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.186]) with mapi id 15.00.0934.000; Thu, 1 May 2014 04:18:34 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt Thread-Index: AQHPY3s4jQ4Ilm00G0yRQcHkptQdJ5spG4CAgAF4PICAAEsRgA== Date: Thu, 1 May 2014 04:18:33 +0000 Message-ID: References: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> <20140430194951.GC31986@elstar.local> In-Reply-To: <20140430194951.GC31986@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(164054003)(189002)(199002)(20776003)(80022001)(81342001)(74662001)(15202345003)(31966008)(92726001)(99286001)(83506001)(99396002)(4396001)(92566001)(86362001)(76482001)(77982001)(76176999)(2656002)(81542001)(83072002)(74502001)(87936001)(54356999)(66066001)(50986999)(85852003)(80976001)(83322001)(19580395003)(36756003)(101416001)(46102001)(15975445006); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Dv4yyUA2gnpR4ubdRs0z15WjA1Y Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.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, 01 May 2014 04:18:44 -0000 Hi Juergen, > Kent, > > the process is somewhat like this > =20 I can=B9t help the timing on this. The reason this is coming up now is because the NETCONF WG wanted to unify the TLS and SSH config, which meant that suddenly the TLS config showed up in a the draft-ietf-netconf-server-model, which is supposed to be about configuring the server (not user auth). Maybe the issue can be traced to 5539bis-00 (Sep 2012), as that is where the TLS-auth config was very first introduced. Perhaps it should=B9ve been put into the draft-ietf-netmod-system-mgmt at that time, but the issue was less visible then since it kind of makes sense that the config would be in the 5539bis. In fact, Tom said as much here: http://www.ietf.org/mail-archive/web/netconf/current/msg08841.html. >Of course, since there is another IETF last call, you can raise an >issue during this second IETF last call if you believe the document is >not ready. And that we should do if we agree that it=B9s the best course of action. > >So keep this in mind when you think about the issue. Are we having an >issue that renders the current version unusable or is this just one of >the many additions one can imagine but which may as well go into a >future revision or augmentation of the data model? In the later case, >I prefer to not pull this document out of the IESG back into the WG. The problem is that if it doesn=B9t go into draft-ietf-netmod-system-mgmt, then the alternative solutions (see bottom) may compound the problem. Now is the time for us to at least look at it and agree what makes sense. I=B9= m all for us doing the right thing, whatever it might be, but we haven=B9t even discussed what that is yet. >PS: I personally do not believe that the user authentation objects in > the sytem draft need configuration of certifications and trust > anchors. Great, the discussion begins, so here goes. The netmod-system-management defines config for User Authentication and says that it does so for SSH because that is NETCONF=B9s mandatory to implement transport. Meanwhile we have netconf-server-model, which is suppose to be just about configuring the NETCONF server, and yet it has user-auth config for TLS (not SSH) in it. This inconsistency is the issue. So, what are our options? 1. Go forward with current inconsistency 2. Only modify draft-ietf-netconf-server-model, but move TLS user-auth out of ietf-server-model into a separate model that augments ietf-system 3. Similar to #2, but move the ietf-system augmentation back to 5539bis 4. Similar to #2, but move the TLS-auth directly (no augmentation) into the ietf-system model defined in draft-ietf-netmod-system-mgmt 5. Move all user-auth config from draft-ietf-netmod-system-mgmt into draft-ietf-netconf-server-model 6. Move all user-auth config from both draft-ietf-netmod-system-mgmt and draft-ietf-netconf-server-model into yet another draft (for instance, draft-ietf-netmod-user-auth?) 7. Anything else? Thanks, Kent