Re: [netmod] Use XML namespaces in YANG document examples
Trimming the cc: From: Carsten Bormann Sent: 10 February 2022 12:43 On 2022-02-10, at 13:22, tom petch wrote: > > If the comments in question had been made at the time of RFC7950 they would > have been most insightful; now they are not IMHO. The comment is insightful, it is just not about this document. I think we need to be able to sort comments into the right bins. (And we need to formalize “Hold for document update” bins for non-errata.) (I’m also still not sure I’ve got an answer to my question about using inconsistent prefixes between YANG and the XML example. What is being demonstrated here?) If you are referring to " Is there a reason to violate the SHOULD?" I did not see that as related to the thread but thought it was answered anyway by Juergen. As he said, the SHOULD gets violated when prefix clash which, in the absence of a registry, a namespace, for prefix is possible. Within the IETF we ought to be able to avoid clashes although good hygiene, like not using two letter prefix helps but there is a world of YANG out there most of which we likely know little of. But the thread was about where prefix may be used and Tim was proposing a different prefix in the XML content. XML defined a namespace for identifiers using a URI, which is clunky, so like many specifications, a short form is created, the prefix, with a mapping thereto. The question then is where is it permissible to use the short form, where the mapping will be understood. I have not looked at the language specification lately but the quotes from it in this thread suggested that it is ok in entity and attribute but not in XML content and needs redefining there except that this is YANG and this is identityref and any parser that does not understand the nature of identityref is a lost cause. But that is at the limit of my understanding (until I re-read the XML specification). I am clear that I think that we are ok with what we are doing and should not start introducing new boiler plate for future examples of YANG. Tom Petch Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] question about unprefixed path in leafref
From: netmod on behalf of Ladislav Lhotka
Sent: 10 February 2022 15:58
"Sterne, Jason (Nokia - CA/Ottawa)" writes:
> This immediately made me worried about all such xxx-ref constructs in YANG
> that I've seen in a few modules.
>
> But looking at IETF interfaces https://datatracker.ietf.org/doc/html/rfc8343
> I see that this error is avoided because interface-ref is fully qualified
> right ?
>
RFC 8407, sec 4.2:
o The local module prefix SHOULD be used instead of no prefix in all
path expressions.
This is particularly important for typedefs that are intended to be used in
other modules.
I cannot recall which I-D triggered it but this point was hammered home, at
least to me, some time back, a year or two perhaps, and I have looked out for
it ever since. It was probably a TEAS I-D that gave different results with
different validators.
Tom Petch
Lada
> typedef interface-ref {
>type leafref {
> path "/if:interfaces/if:interface/if:name";
>}
>description
> "This type is used by data models that need to reference
> interfaces.";
> }
>
> Jason
>
> From: netmod On Behalf Of Jernej Tuljak
> Sent: Wednesday, February 9, 2022 3:47 AM
> To: Fengchong (frank) ;
> netmod@ietf.org
> Subject: Re: [netmod] question about unprefixed path in leafref
>
>
> On 08/02/2022 03:40, Fengchong (frank) wrote:
> Hi all,
>
> In RFC7950 sec6.4.1 says:
>
>
> 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.13). Inside a
> typedef, that namespace is affected by
>
> where the typedef is referenced. If a typedef is defined and
>
> referenced within a grouping, the namespace is affected by where
>
> the grouping is used (see Section
> 7.13).
>
> But in module openconfig-aft-network-instance:
>
> augment "/oc-ni:network-instances/oc-ni:network-instance/" +
> "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state" {
>
> description
> "Add leaves that require referencing of a network instance to the
> operational state parameters of a next-hop within the AFT for IPv4
> unicast.";
>
> uses aft-nexthop-ni-state;
> }
>
> grouping aft-nexthop-ni-state {
> description
> "Operational state parameters relating to a next-hop which reference a
> network instance.";
>
> leaf network-instance {
> type oc-ni:network-instance-ref;
> description
> "The network-instance within which the next-hop should be resolved.
> When this leaf is unspecified, the next-hop is resolved within
> the local instance.";
> }
> }
>
> The typedef network-instance-ref is defined in module
> openconfig-network-instance:
>
> typedef network-instance-ref {
> type leafref {
> path "/network-instances/network-instance/config/name";
> }
> description
> "A re-usable type that can be referenced within other
>modules that references a network instance.";
> }
>
> The leafref’s path is a unprefixed path.
>
> So, according RFC7950, the typedef network-instance-ref is referenced in leaf
> network-instance, and the leaf is inside grouping aft-nexthop-ni-state, and
> this grouping is used in augment
> "/oc-ni:network-instances/oc-ni:network-instance/" +
> "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state"
> So the path "/network-instances/network-instance/config/name" ‘s namespace is
> module openconfig-aft-network-instance’s namespace. But in fact, there is no
> node called network-instances with namespace:
> http://openconfig.net/yang/aft/ni.
>
> Is it incorrect?
>
> I try to use pyang to compile it, and no error is reported.
>
> These modules are written in YANG 1.0, therefore RFC6020 applies, not
> RFC7950. This was one of the cases where RFC6020 was unclear, hence new text
> you quote from RFC7950. If you change openconfig-network-instance to YANG
> 1.1, pyang should report an error for that "path" when the "typedef" gets
> used in openconfig-aft-network-instance.
>
> Jernej
>
>
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including, but
> not limited to, total or partial disclosure, reproduction, or dissemination)
> by persons other than the intended recipient(s) is prohibited. If you receive
> this e-mail in error, please notify the sender by phone or email immediately
> and delete it!
>
>
>
>
>
Re: [netmod] question about unprefixed path in leafref
"Sterne, Jason (Nokia - CA/Ottawa)" writes:
> Hi all,
>
> This immediately made me worried about all such xxx-ref constructs in YANG
> that I've seen in a few modules.
>
> But looking at IETF interfaces https://datatracker.ietf.org/doc/html/rfc8343
> I see that this error is avoided because interface-ref is fully qualified
> right ?
>
RFC 8407, sec 4.2:
o The local module prefix SHOULD be used instead of no prefix in all
path expressions.
This is particularly important for typedefs that are intended to be used in
other modules.
Lada
> typedef interface-ref {
>type leafref {
> path "/if:interfaces/if:interface/if:name";
>}
>description
> "This type is used by data models that need to reference
> interfaces.";
> }
>
> Jason
>
> From: netmod On Behalf Of Jernej Tuljak
> Sent: Wednesday, February 9, 2022 3:47 AM
> To: Fengchong (frank) ;
> netmod@ietf.org
> Subject: Re: [netmod] question about unprefixed path in leafref
>
>
> On 08/02/2022 03:40, Fengchong (frank) wrote:
> Hi all,
>
> In RFC7950 sec6.4.1 says:
>
>
> 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.13). Inside a
> typedef, that namespace is affected by
>
> where the typedef is referenced. If a typedef is defined and
>
> referenced within a grouping, the namespace is affected by where
>
> the grouping is used (see Section
> 7.13).
>
> But in module openconfig-aft-network-instance:
>
> augment "/oc-ni:network-instances/oc-ni:network-instance/" +
> "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state" {
>
> description
> "Add leaves that require referencing of a network instance to the
> operational state parameters of a next-hop within the AFT for IPv4
> unicast.";
>
> uses aft-nexthop-ni-state;
> }
>
> grouping aft-nexthop-ni-state {
> description
> "Operational state parameters relating to a next-hop which reference a
> network instance.";
>
> leaf network-instance {
> type oc-ni:network-instance-ref;
> description
> "The network-instance within which the next-hop should be resolved.
> When this leaf is unspecified, the next-hop is resolved within
> the local instance.";
> }
> }
>
> The typedef network-instance-ref is defined in module
> openconfig-network-instance:
>
> typedef network-instance-ref {
> type leafref {
> path "/network-instances/network-instance/config/name";
> }
> description
> "A re-usable type that can be referenced within other
>modules that references a network instance.";
> }
>
> The leafref’s path is a unprefixed path.
>
> So, according RFC7950, the typedef network-instance-ref is referenced in leaf
> network-instance, and the leaf is inside grouping aft-nexthop-ni-state, and
> this grouping is used in augment
> "/oc-ni:network-instances/oc-ni:network-instance/" +
> "oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state"
> So the path "/network-instances/network-instance/config/name" ‘s namespace is
> module openconfig-aft-network-instance’s namespace. But in fact, there is no
> node called network-instances with namespace:
> http://openconfig.net/yang/aft/ni.
>
> Is it incorrect?
>
> I try to use pyang to compile it, and no error is reported.
>
> These modules are written in YANG 1.0, therefore RFC6020 applies, not
> RFC7950. This was one of the cases where RFC6020 was unclear, hence new text
> you quote from RFC7950. If you change openconfig-network-instance to YANG
> 1.1, pyang should report an error for that "path" when the "typedef" gets
> used in openconfig-aft-network-instance.
>
> Jernej
>
>
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including, but
> not limited to, total or partial disclosure, reproduction, or dissemination)
> by persons other than the intended recipient(s) is prohibited. If you receive
> this e-mail in error, please notify the sender by phone or email immediately
> and delete it!
>
>
>
>
> ___
>
> 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
Head, CZ.NIC Labs
PGP Key ID:
[netmod] YANG Versioning Weekly Call Minutes - 2022-02-08
YANG Versioning Weekly Call Minutes - 2022-02-08 We had a few new people join the call on Tuesday - that's great. Thanks for joining in. It may take a few calls to get into the swing of things. Discussed on the call: - reviewed some action items that have progressed: - #74 items (a) and (c) about schema terminology. Jason pulled PR 127 into Master. - #74 items (e) and (i) discussed. Jason to wrap up #74. - #105/#125: Bo provided text. Will remove version history section. Needs 1 or 2 reviews. - Discussed Rob's proposal to consider an "optional" flag in packages against modules & included packages. Needs further discussion. - New issue to be raised: guidelines on how a vendor should construct their packages (e.g. core package, with other per-release packages) - For future meetings: - schema mount & packages - IETF 113 prep (meetings March 19-25) -- Versioning work on Github: https://github.com/netmod-wg/yang-ver-dt -- Weekly webex call details: Meeting number (access code): 161 096 5630 Meeting password: semver? Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 10:00 AM, (UTC-05:00) Eastern Time (US & Canada) 9:00 AM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1610965630## Call-in toll number (US/Canada) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] question about unprefixed path in leafref
Hi all,
This immediately made me worried about all such xxx-ref constructs in YANG that
I've seen in a few modules.
But looking at IETF interfaces https://datatracker.ietf.org/doc/html/rfc8343 I
see that this error is avoided because interface-ref is fully qualified right ?
typedef interface-ref {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
description
"This type is used by data models that need to reference
interfaces.";
}
Jason
From: netmod On Behalf Of Jernej Tuljak
Sent: Wednesday, February 9, 2022 3:47 AM
To: Fengchong (frank) ;
netmod@ietf.org
Subject: Re: [netmod] question about unprefixed path in leafref
On 08/02/2022 03:40, Fengchong (frank) wrote:
Hi all,
In RFC7950 sec6.4.1 says:
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.13). Inside a
typedef, that namespace is affected by
where the typedef is referenced. If a typedef is defined and
referenced within a grouping, the namespace is affected by where
the grouping is used (see Section
7.13).
But in module openconfig-aft-network-instance:
augment "/oc-ni:network-instances/oc-ni:network-instance/" +
"oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state" {
description
"Add leaves that require referencing of a network instance to the
operational state parameters of a next-hop within the AFT for IPv4
unicast.";
uses aft-nexthop-ni-state;
}
grouping aft-nexthop-ni-state {
description
"Operational state parameters relating to a next-hop which reference a
network instance.";
leaf network-instance {
type oc-ni:network-instance-ref;
description
"The network-instance within which the next-hop should be resolved.
When this leaf is unspecified, the next-hop is resolved within
the local instance.";
}
}
The typedef network-instance-ref is defined in module
openconfig-network-instance:
typedef network-instance-ref {
type leafref {
path "/network-instances/network-instance/config/name";
}
description
"A re-usable type that can be referenced within other
modules that references a network instance.";
}
The leafref’s path is a unprefixed path.
So, according RFC7950, the typedef network-instance-ref is referenced in leaf
network-instance, and the leaf is inside grouping aft-nexthop-ni-state, and
this grouping is used in augment
"/oc-ni:network-instances/oc-ni:network-instance/" +
"oc-ni:afts/oc-ni:next-hops/oc-ni:next-hop/oc-ni:state"
So the path "/network-instances/network-instance/config/name" ‘s namespace is
module openconfig-aft-network-instance’s namespace. But in fact, there is no
node called network-instances with namespace: http://openconfig.net/yang/aft/ni.
Is it incorrect?
I try to use pyang to compile it, and no error is reported.
These modules are written in YANG 1.0, therefore RFC6020 applies, not RFC7950.
This was one of the cases where RFC6020 was unclear, hence new text you quote
from RFC7950. If you change openconfig-network-instance to YANG 1.1, pyang
should report an error for that "path" when the "typedef" gets used in
openconfig-aft-network-instance.
Jernej
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not
limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive this
e-mail in error, please notify the sender by phone or email immediately and
delete it!
___
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
Re: [netmod] I-D Action: draft-ietf-netmod-node-tags-05.txt
Hi, folks: v-05 is posted, which address recent review from YANG Doctor Directorate and Adrian, thanks Adrian and Mahesh for valuable input and suggestions. The main changes are: * Add user tag formatting clarification; * Provide guidance to the Designated Expert for evaluation of YANG Data Object Tag registry and YANG Data Object Tag prefix registry. * Update the figure 1 and figure 2 with additional tags. * Security section enhancement for user tag management. * Change data object name into name in the module. * Other Editorial changes to address Adrian's comments and comments during YANG doctor review. One open issue is waiting for being confirmed, i.e., Are there any risks associated with an attacker adding or removing tags so that a requester gets the wrong data? Related security measures text has been integrated in v05. The diff is: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-node-tags-05 Comments and additional review are welcome! -Qin -邮件原件- 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 internet-dra...@ietf.org 发送时间: 2022年2月10日 20:52 收件人: i-d-annou...@ietf.org 抄送: netmod@ietf.org 主题: [netmod] I-D Action: draft-ietf-netmod-node-tags-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Self-Describing Data Object Tags Authors : Qin Wu Benoit Claise Peng Liu Zongpeng Du Mohamed Boucadair Filename: draft-ietf-netmod-node-tags-05.txt Pages : 30 Date: 2022-02-10 Abstract: This document defines a method to tag data objects associated with operation and management data in YANG modules. The expectation is for this YANG data object tagging method to be used to classify data objects from different YANG modules and identify their characteristics data. Tags may be registered as well as assigned during the module definition, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC 8407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-node-tags-05 Internet-Drafts are also available by rsync at rsync.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
[netmod] I-D Action: draft-ietf-netmod-node-tags-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Self-Describing Data Object Tags Authors : Qin Wu Benoit Claise Peng Liu Zongpeng Du Mohamed Boucadair Filename: draft-ietf-netmod-node-tags-05.txt Pages : 30 Date: 2022-02-10 Abstract: This document defines a method to tag data objects associated with operation and management data in YANG modules. The expectation is for this YANG data object tagging method to be used to classify data objects from different YANG modules and identify their characteristics data. Tags may be registered as well as assigned during the module definition, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC 8407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-node-tags-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Use XML namespaces in YANG document examples
On 2022-02-10, at 13:22, tom petch wrote: > > If the comments in question had been made at the time of RFC7950 they would > have been most insightful; now they are not IMHO. The comment is insightful, it is just not about this document. I think we need to be able to sort comments into the right bins. (And we need to formalize “Hold for document update” bins for non-errata.) (I’m also still not sure I’ve got an answer to my question about using inconsistent prefixes between YANG and the XML example. What is being demonstrated here?) Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Use XML namespaces in YANG document examples
From: netmod on behalf of Jürgen Schönwälder Sent: 07 February 2022 20:03 While adding such a disclaimer may help you to move your document forward (which I assume is your main priority), this looks to me like a disclaimer added to an arbitrary YANG document for the sake of making a reviewer happy while (i) we never did this before and (ii) we likely have no plan to do this in the future. If this issue is really important, then someone should write an I-D or an errata for RFC 7950 that clarifies this for _all_ YANG modules. Given that YANG is 11+ years old, I am not convinced this clarification is needed, but that certainly may be a biased opinion. Hence, my preference is to add no disclaimer and to move forward. Spot on. I see a functional problem with expert reviews at a late stage in the process. I have had a lot of problems with them in the past year or two and almost always they arise because the expert is viewing the work from the limited point of view of their expertise and not seeing the work as part of the output of the IETF, a large existing body of work which I believe needs to be coherent (a favorite word of mine). If the comments in question had been made at the time of RFC7950 they would have been most insightful; now they are not IMHO. I also see it as symptomatic that this issue was raised over an I2NSF I-D which I brought to the attention of the NETMOD WG earlier this year and would say that the consensus of the WG at that time was that the comment was unjustified. Now we get the same comment on DHCP. How many more times is it going to come up? On a bad day, I see experts descending from an ivory tower, causing mayhem and disappearing until the next time but I admit that that is an extreme view. Expert opinions are useful input but should be just input to the consensus whereas at times, especially at Last Call, they may be taken at gospel to the detriment of the cohesion of the IETF. Tom Petch /js On Mon, Feb 07, 2022 at 08:40:49PM +0100, ianfar...@gmx.com wrote: > Hi, > > Reading back through the discussion, I think I can summarise the outcome to > the following 2 points: > > 1,The examples in the DHCPv6 YANG draft can keep the current use of XML > prefixes (e.g. ianaift:ethernetCsmacd) > > 2, In the XML examples appendix, I will change the first paragraph to read: > > XML Examples for DHCPv6 Element Configuration > > This section contains XML examples of data trees for the different > DHCPv6 elements. In order for the XML data to be used correctly, > the XML prefix must be the same as the namespace prefix. i.e, for > The client configuration example, the characters before the colon > (or 'ianaift:’ in the "interface/type” element content) must match the > xmlns defined for "urn:ietf:params:xml:ns:yang:iana-if-type”. In this > case xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type”. > Therefore, XML software must be chosen that makes the namespace prefix > information available. > > Does this sound like the right way to proceed? > > Thanks, > Ian > > > > > > On 4. Feb 2022, at 16:15, Martin Björklund wrote: > > > > Jernej Tuljak wrote: > >> > >> > >> On 04/02/2022 08:18, Martin Björklund wrote: > >>> Tim Bray wrote: > On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund > wrote: > > > If an XML document has , won't the XML processor > > pass the attribute "xmlns:bar" and its value to the application? This > > should be enough even if the XML processor doesn't provide a mapping > > table between prefix and namespace (it requires more work in the > > application of course). > > > Nope, there's no requirement that they do and some don't. > >>> Does this mean that an XML processor might not pass attributes in > >>> general to the application? If so, we might have other similar > >>> problems. Or does it mean that an XML processor might just not pass > >>> these "special" attributes? If so, where is that specified? (I tried > >>> to find this info in the spec, but didn't find it). > >> > >> Names that start with "xml" (case insensitive) are reserved by XML 1.0 > >> specification, "xmlns" in an attribute name included (2.3 Common > >> Syntactic Constructs). They are special. There is also a guideline on > >> colon usage within names. > > > > Yes, I know. But I can't see that the spec says that attributes w/ > > reserved names should be treated differently wrt. the application than > > other attributes. > > > >> All processors I'm aware of differentiate between attributes and > >> namespace attributes in their APIs. What Tim is probably saying is > >> that some XML processors either don't implement Namespaces in XML 1.0 > >> or need to be explicitly configured to become "namespace aware". If > >> not configured as namespace aware, they might simply ignore namespace > >> attributes therefore not passing them. If they are configured as > >> namespace aware, they might remove prefix information and pass
[netmod] FW: New Version Notification for draft-ma-netmod-immutable-flag-00.txt
Hi, all This "immutable metadata annotation" document is derived from draft-ma-netmod-with-system. It can be used to decorate the data node instances which are "config true" but cannot be changed by configuration operations. There are some ongoing discussion around this work: https://mailarchive.ietf.org/arch/msg/netmod/lk5BuvPCbLcVui5bFKxgNFSWOCw/ Please feel free to review and comment. Best Regards, Qiufang Ma -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Thursday, February 10, 2022 7:23 PM To: Hongwei Li ; Qin Wu ; Qin Wu ; maqiufang (A) Subject: New Version Notification for draft-ma-netmod-immutable-flag-00.txt A new version of I-D, draft-ma-netmod-immutable-flag-00.txt has been successfully submitted by Qiufang Ma and posted to the IETF repository. Name: draft-ma-netmod-immutable-flag Revision: 00 Title: Immutable Metadata Annotation Document date: 2022-02-10 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-00.txt Status: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag Abstract: This document defines a metadata annotation [RFC7952] named "immutable" to indicate the immutability of a particular instantiated data node. Any instantiated data node annotated with immutable="true" by the server is read-only to the clients of YANG- driven management protocols, such as NETCONF, RESTCONF and other management operations (e.g., SNMP and CLI requests). The IETF Secretariat ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
