Re: [netmod] xpath expressions in JSON

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Thu, 18 October 2018 13:17 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5242130F2F for <netmod@ietfa.amsl.com>; Thu, 18 Oct 2018 06:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSjXzo9FdR5s for <netmod@ietfa.amsl.com>; Thu, 18 Oct 2018 06:17:56 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1575130F1A for <netmod@ietf.org>; Thu, 18 Oct 2018 06:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4910; q=dns/txt; s=iport; t=1539868675; x=1541078275; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mRu3pmAqXcCimSchf+ch3LEiLr1OFtJ17KKREzZh43Q=; b=hMBovf+anokcW5tz0mu0KXx9q75W0mOisWnj+FhuPTIhTwSqjhHvToim WRSCB/Q+Vs2i8c/DLTy7dmqMliGMMLdCPOMRXAqI2i5KcgfVbeO0PEzR5 RDeTFVfX7ZcGLq7FOj1iyUe4X92lYBKWOD2KvppDloc4eriOHuEZkgDE+ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAADjhshb/5BdJa1jGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBVQUqZn8oCoNriBeMG4FolzSBegsBARgLhANGAheEaiE0DQ0BAwEBAgEBAm0cDIU6AgEDAQEhETobAgEIDgwCJgICAiULFRACBAESgyABggEPphOBLooeBYELikIXgUE/gREnDBOCTIMbAQGBYReCbDGCJgKIZQSFWY92CQKQZReQJ5YdAhEUgSYdOIFVcBU7KgGCQYImF3wBC4dThT5viiGBHwEB
X-IronPort-AV: E=Sophos;i="5.54,396,1534809600"; d="scan'208";a="250133401"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2018 13:17:53 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w9IDHrnQ028508 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Oct 2018 13:17:53 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Oct 2018 08:17:52 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 18 Oct 2018 08:17:53 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] xpath expressions in JSON
Thread-Index: AQHUYIqyJUA4hM8yQEuWRAlaWHhia6UYv5+AgAAV+YCAAIZOgIAASaoAgABHYACAAC1hgIAAEM2AgAAGGwCAAAHbgIAAB16AgABShQCAAAlqgIABCfeAgAmNmgD//+uuAA==
Date: Thu, 18 Oct 2018 13:17:53 +0000
Message-ID: <6ED21B8D-A711-4489-AECB-32DCF5947C02@cisco.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com>
In-Reply-To: <20181018.123036.731934458688841323.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.253.209]
Content-Type: text/plain; charset="utf-8"
Content-ID: <14C063152F07A048A49AC94425609664@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/bqdC4qTk1CN2n8tD7Sz6YyP5T5A>
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2018 13:18:05 -0000

We can't time travel and as you mentioned option A has consistency within each encoding, so I'm also for option A. 

Regards,
Reshad.

On 2018-10-18, 6:30 AM, "netmod on behalf of Martin Bjorklund" <netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:

    Hi,
    
    Going back to the most urgent issue, what is this WG's recommendation
    for the subscribed-notifications draft in NETCONF wrt/ their usage of
    yang:xpath1.0 in filters?
    
    To summarize:
    
    We already have
    
      o  instance-identifier in XML uses prefixes from the XML document
      o  instance-identifier in JSON uses module names as prefixes
      o  XPath in NETCONF filter uses prefixes from the XML document
      o  XPath in JSON query filter uses module names as prefixes
    
    
    Alternative A:
    --------------
    
    Use different encodings for "stream-xpath-filter" as well, depending
    on if it is XML or JSON.
    
    We would do in SN:
    
        o  If the node is encoded in XML, the set of namespace
           declarations are those in scope on the
           'stream-xpath-filter' leaf element.
    
        o  If the node is encoded in JSON, the set of namespace
           declarations is the set of prefix and namespace pairs
           for all supported YANG modules, where the prefix is
           the YANG module name and the namespace is as defined
           by the "namespace" statement in the YANG module.
    
    Pro: the format is consistent within each encoding.
    
    Con: unclear how to handle other encodings.
    Con: we keep using context-depending encodings.
    
    We could probably add that CBOR uses the same representation as JSON.
    
    Example in XML:
    
      <stream-xpath-filter
          xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
          xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
        /if:interfaces/if:interface/ip:ipv4
      </stream-xpath-filter>
    
    Example in JSON:
    
      "stream-xpath-filter":
        "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
    
    
    
    Alternative B:
    --------------
    
    Use a non-context depending encoding, with the module name as prefix.
    
    We would do in SN:
    
        o  The set of namespace
           declarations is the set of prefix and namespace pairs
           for all supported YANG modules, where the prefix is
           the YANG module name and the namespace is as defined
           by the "namespace" statement in the YANG module.
    
    Pro: the format is independent from the protocol encoding
    
    Con: in XML, this leaf is treated differently from other XPath
         expressions, such as get-config filter and nacm rules.
    
    Example in XML:
    
      <stream-xpath-filter>
        /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
      </stream-xpath-filter>
    
    Example in JSON:
    
      "stream-xpath-filter":
        "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
    
    
    My proposal is A.  I think it is more important with consistency
    within each encoding than across encodings.
    
    (This said, I would like to have a context-independent encoding of all
    YANG types in the future.  But not now.)
    
    
    
    
    /martin
    
    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod