Re: [Netconf] Clarification about additional attributes at Messages(RPC) layer
Shiva Kumar Pathori <pathori@gmail.com> Wed, 31 January 2018 05:27 UTC
Return-Path: <pathori@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72DB12EBBB for <netconf@ietfa.amsl.com>; Tue, 30 Jan 2018 21:27:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.291
X-Spam-Level:
X-Spam-Status: No, score=0.291 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YFibSKXg4Msb for <netconf@ietfa.amsl.com>; Tue, 30 Jan 2018 21:27:09 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805D512EB80 for <netconf@ietf.org>; Tue, 30 Jan 2018 21:27:09 -0800 (PST)
Received: by mail-oi0-x235.google.com with SMTP id m83so9649515oik.8 for <netconf@ietf.org>; Tue, 30 Jan 2018 21:27:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lLNzydC9LcxtWnsS29+ZxqtLLc82xItNpTBkbK8tAUo=; b=BveL4okgREcsPHZrXuWEwzx7R9JfChGdMWue13NfU2uObblVvbgK61NwUWKhyzJwPp hGyllYG4HlXr5l27dSsELUkBcHEp1vE9HKt1iUIR4BvWcQH/+1yiReYvd1iO2Aggo64Y WFrZkEhZWbwUHkFR7NiOZKxuwnUiDIo7fqXongDdEoqza3/3f77l4wM5HIH4VZ3n26uH mY7nmZbZBlQaflWKvuTrigsun12OoY27tIXCLLatuoA41b76pLUubJr4tHMEsFTadmso 1KQJoiROIDL286AFuuk76w9EsJ1VP+B/UJIux6JASyr5yfq4lUGpy7OoD7uWryNnDeGq b26w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lLNzydC9LcxtWnsS29+ZxqtLLc82xItNpTBkbK8tAUo=; b=E6BTfQtZBbyv3sbXr42n+48vlVJ77wlVcGMpzx2F7esUHEIGDkbGlIjAZ24HWrNFf4 7MefBXuxODvR88DLAYScs+NvGmgCGHX3gTlxqG0z13R9HKAuKUNR5q3VzrYxBMVglbZJ abKPBsAiNuPs2WQefDG8lcxlfJ726nnXG49xWS2VtaAdW28b5trn7FhLF0LM9rzxvcI6 l4Je0u9gwh4KSrrqd2YN8L6Am0jCSWfT1jcx2zzkQ5OS3SZUK2BUSUBq9c4CJMjkpFBH oPe/z/G7JPFYzFHO1yQkI6K4jIDUZClsuaImGWXabn54qGsbrxPG5Wu5gaVDBq9mY5/P C48w==
X-Gm-Message-State: AKwxytfdaWc1hL/K8SrkOP6cdsaAXsEdAH+gws4CA5rcVUyW1XFmhuMu v6sHrZEN4GU5NryN76642YfBw/FN4CM33pQlTdI=
X-Google-Smtp-Source: AH8x224tasq7leOmVm7AkVL/KRf9E2S57HA6is1Bpx7G36/UxuU8goX8YT12/lZ14FxGd36iSrDnuCM2VAMIKzso4n0=
X-Received: by 10.202.191.85 with SMTP id p82mr10256704oif.344.1517376428756; Tue, 30 Jan 2018 21:27:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.50.164 with HTTP; Tue, 30 Jan 2018 21:27:08 -0800 (PST)
Received: by 10.157.50.164 with HTTP; Tue, 30 Jan 2018 21:27:08 -0800 (PST)
In-Reply-To: <CAJtYN8Jte2O52Hrb3wgD0EgosG4fn0=oUwn4gHxTjXciuqGZ1g@mail.gmail.com>
References: <CAJtYN8LRQb_HzbN7CmXPPwDKnRXK=YhWyrku223cQ-NVZxN6+Q@mail.gmail.com> <805AA544-8B1D-4F80-999C-AABB3F5D3253@juniper.net> <DC672864-B29D-4F52-BF89-CCB09539CC30@gmail.com> <D2073184-BC0D-4471-BCE0-F6EC532BA3AD@juniper.net> <CAJtYN8Jte2O52Hrb3wgD0EgosG4fn0=oUwn4gHxTjXciuqGZ1g@mail.gmail.com>
From: Shiva Kumar Pathori <pathori@gmail.com>
Date: Wed, 31 Jan 2018 10:57:08 +0530
Message-ID: <CAJtYN8JPGzzBj=+zfpMSgkX+r6k+aHdTCq-qDvp6eDmH9aGGgg@mail.gmail.com>
To: Kent Watsen <kwatsen@juniper.net>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, netconf@ietf.org
Content-Type: multipart/alternative; boundary="001a113dd23206d36505640bbbc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WlVtD3ZZm0b7ThYoIolqkFXFadU>
Subject: Re: [Netconf] Clarification about additional attributes at Messages(RPC) layer
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2018 05:27:12 -0000
I mentioned the module name wrongly, it is ietf-yang-metadata On 31-Jan-2018 10:46 AM, "Shiva Kumar Pathori" <pathori@gmail.com> wrote: > Do we need to have some mechanism like ietf-yanag-metadata.yang that > allows defining the attributes at data instances so that the clients are > aware of the additional attributes. So that if the client is interested > will process otherwise ignores it. > > On 31-Jan-2018 12:23 AM, "Kent Watsen" <kwatsen@juniper.net> wrote: > >> >> >> Section 4.2 says that "message-id" is mandatory, and that the server MUST >> >> return any additional attributes included in the <rpc> element. But it >> doesn't >> >> say anything that limits a server returning even more. >> >> >> >> My assumption is that it is allowed. Specifically, from an XML document >> >> encoding perspective, it is always valid to move "xmlns" prefix >> declarations >> >> to ancestor elements… >> >> >> >> K. // contributor >> >> >> >> >> >> On 1/30/18, 1:25 PM, "Mahesh Jethanandani" <mjethanandani@gmail.com> >> wrote: >> >> >> >> [As contributor] >> >> >> >> On Jan 30, 2018, at 6:54 AM, Kent Watsen <kwatsen@juniper.net> wrote: >> >> >> >> >> >> I believe that this is allowed by [1], but worry about interoperability >> due to the "config-id" attribute being a proprietary extension. >> >> >> >> [1] https://tools.ietf.org/html/rfc6241#section-4.2 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6241-23section-2D4.2&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iT-5cpJaklJMJbEVRv4fgPBCu63AMMak0WbYDDMdYts&s=0FHMPEAKMzcNdQB20gJvvoJinRvDVVr13531hZJHbtY&e=> >> >> >> >> Per that section, what is returned is what was originally in the request. >> The nc-ext is something that has been added in the response, and was not >> existing in the request. >> >> >> >> To Shiva’s question, it is not clear how the clients will react to >> additional data in the <rpc-reply>. Will they just ignore it, or barf at it? >> >> >> >> >> >> Kent // contributor >> >> >> >> >> >> Assuming the namespace prefix is there to support >> >> >> >> On 1/29/18, 3:17 PM, "Netconf on behalf of Shiva Kumar Pathori" < >> netconf-bounces@ietf.org on behalf of pathori@gmail.com> wrote: >> >> >> >> Hi, >> >> Can somebody clarify below <rpc-reply> sent by the NETCONF server will >> break the NETCONF client functionality. Additional attribute information is >> shown in RED color. >> >> >> >> <rpc message-id="101" >> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> <edit-config> >> >> <target> >> >> <running/> >> >> </target> >> >> <config> >> >> <top xmlns="http://example.com/schema/1.2/config <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_schema_1.2_config&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nAjM7pDWG7HS1viFkN6mWV_1Ii2GVce-FvEqf3h0gfo&s=LQjMxXfz35-ysUajs_4pgqhw9Cmbna4-0672JlBXzNI&e=>"> >> >> <interface> >> >> <name>Ethernet0/0</name> >> >> <mtu>1500</mtu> >> >> </interface> >> >> </top> >> >> </config> >> >> </edit-config> >> >> </rpc> >> >> >> >> <rpc-reply message-id="101" >> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >> >> *xmlns:nc-ext="http://sample.com/netconf/ext <https://urldefense.proofpoint.com/v2/url?u=http-3A__sample.com_netconf_ext&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nAjM7pDWG7HS1viFkN6mWV_1Ii2GVce-FvEqf3h0gfo&s=H__4DCa9XJZJTIQ_Ewl7nAey_4XKXSKLAh-48KhPxMI&e=>" nc-ext:config-id="1"*> >> >> <ok/> >> >> </rpc-reply> >> >> >> >> I have just tried with MG SOFT NETCONF browser and worked fine, I think >> MG SOFT browser ignored these attributes. >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iT-5cpJaklJMJbEVRv4fgPBCu63AMMak0WbYDDMdYts&s=rw5qXFv9bAYyUmvp0t9QdGF7ogdxJrQJWUEdpRzAE4A&e=> >> >> >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> >> >> >>
- [Netconf] Clarification about additional attribut… Shiva Kumar Pathori
- Re: [Netconf] Clarification about additional attr… Kent Watsen
- Re: [Netconf] Clarification about additional attr… Mahesh Jethanandani
- Re: [Netconf] Clarification about additional attr… Kent Watsen
- Re: [Netconf] Clarification about additional attr… Shiva Kumar Pathori
- Re: [Netconf] Clarification about additional attr… Shiva Kumar Pathori
- Re: [Netconf] Clarification about additional attr… Martin Bjorklund