Re: [netmod] 6991bis: address-with-prefix-length

[Alex Campbell]

I don't think this is joining an address with a prefix - this is joining an 
address with a prefix *length*.
If it was two separate values, it would still be constraining the address to be 
covered by the prefix, since there would be no way to define a prefix that the 
address didn't cover.

Also a distinction from ipv4-prefix is that an ipv4-prefix is completely 
meaningless if either part is removed, whereas an ip-address-and-prefix-length 
still specifies an IP address if you remove the prefix length.

Alex


From: netmod  on behalf of Christian Hopps 

Sent: Wednesday, 3 April 2019 7:52 a.m.
To: Martin Bjorklund
Cc: netmod@ietf.org
Subject: Re: [netmod] 6991bis: address-with-prefix-length

> On Apr 2, 2019, at 2:27 PM, Martin Bjorklund  wrote:
>
> "Rob Wilton (rwilton)"  wrote:
>> Hi Acee,
>>
>> Having re-read the thread, I think that "ip-address-prefix" is going
>> to be confusing, since I had incorrectly assumed that the type being
>> defined was an IP prefix, but as you have pointed out there is already
>> a type for that.
>>
>> I think that we need to choose this name very carefully or otherwise I
>> suspect that folks will accidentally use the wrong type.
>>
>> So having the type as "ip-address-and-prefix-length" or
>> "ip-addr-and-prefix-len" now seems like a clearer choice to me.
>
> The combined type really specifies (i) an ip address and (ii) an ip
> prefix.  The prefix happens to be specified with a length indicator.
> So I think the name "ip-address-and-prefix" is the correct one.
>
>> I
>> think that I also now agree with Martin that this is really merging
>> two values into one leaf.
>
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.

(Again :) this is not just joining two values, it is also constraining the 
address value to be a value covered by the prefix. The common use case is for 
interface state where the interface has an address which should be within the 
prefix assigned to the network the interface attaches to.

This isn't just about saving space.

I also agree that "-and-" is a really good idea, saving a few characters in an 
identifier when doing so has shown to cause the identifier to be misunderstood 
is not an optimization IMO.

Thanks,
Chris.

>
>
> /martin
>
>
>> Where is this type going to be used?  Is it only used for configuring
>> host address/prefix?  Or are there other uses cases as well?
>>
>> Thanks,
>> Rob
>>
>>
>>> -Original Message-
>>> From: Acee Lindem (acee) 
>>> Sent: 02 April 2019 16:52
>>> To: Rob Wilton (rwilton) ; Martin Bjorklund
>>> >> f.com>; j.schoenwael...@jacobs-university.de
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>>
>>> Hi Rob,
>>>
>>> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
>>> >> boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
>>>
>>>
>>>
 -Original Message-
 From: netmod  On Behalf Of Martin
>>> Bjorklund
 Sent: 02 April 2019 13:47
 To: j.schoenwael...@jacobs-university.de
 Cc: netmod@ietf.org
 Subject: Re: [netmod] 6991bis: address-with-prefix-length

 Juergen Schoenwaelder  wrote:
> If you go back ~20 messages, my proposal was ip-address-prefix,
> ipv4-address-prefix, and ipv6-address-prefix.

 Do we agree that this type really specifies two values in one?  If so
 I think
>>> the
 "and" is useful.
>>>
>>>Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
>>>
>>> This was my confusion as well since the ipv4-prefix and ipv6-prefix
>>> types
>>> (ietf-inet-types) have been used when they probably shouldn't have
>>> been.
>>> Note that they both have the constraint of not allowing the host bits
>>> to be set
>>> should they should be used in situations like interface address
>>> assignment.
>>>
>>> Excerpted from RFC6991 ipv4-type definition (note the last sentence):
>>> description
>>>"The ipv4-prefix type represents an IPv4 address prefix.
>>> The prefix length is given by the number following the
>>> slash character and must be less than or equal to 32.
>>>
>>> A prefix length value of n corresponds to an IP address
>>> mask that has n contiguous 1-bits from the most
>>> significant bit (MSB) and all other bits set to 0.
>>>
>>> The canonical format of an IPv4 prefix has all bits of
>>> the IPv4 address set to zero that are not part of the
>>> IPv4 prefix.";
>>>
>>>So, I think that the names above are probably right, or otherwise if
>>>you
>>> want the "and" then perhaps it should be
>>> "ip-address-and-prefix-length" -
>>> which seems clunky?
>>>
>>> I think the original suggestion of ipxx-address-prefix would be ok.
>>>
>>> Thanks,
>>> Acee
>>>
>>>Thanks,
>>>Rob
>>>
>>>

 Also note that the current text in RFC 6991 says:

 The ipv4-pr

Re: [netmod] Question on draft-wu-netmod-factory-default

[Alex Campbell]

As I understand it,the only purpose for the candidate and startup datastores is 
to indirectly set the contents of the running datastore.

Therefore it wouldn't make sense to have different factory defaults for the 
running, startup and candidate datastores. And those are the only writable ones.

Joe, which other datastores were you thinking of?

Alex



From: netmod  on behalf of joel jaeggli 

Sent: Tuesday, 26 March 2019 8:18 p.m.
To: Joe Clarke; netmod@ietf.org
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default

On 3/25/19 07:14, Joe Clarke wrote:
> I support the need for being able to reset a DS to its factory default.
> However, I have a question on the current design of the model and the
> "factory-default" DS.
>
> It seems to me that this is a single DS that might have been intended to
> reset running or startup.  However, what if I have different DSes that
> each have unique factory default data?  If I choose to extend
> factory-default with a new identity of my other DS, how can I indicate
> that the target DS will be reset to _that_ DS?  Does that make sense?
>
> Or if I do a  on a factory-default DS, how do I know what
> other DSes does this DS pertain?  Perhaps the server will use this to
> reset a given DS, but how would a user know that (other than perhaps
> naming of the factory-default DS)?
>
> Maybe the module needs a mapping to let the client know what DS will be
> used to reset what other DS?

the germ of the idea is sensible enough. reset a DS to it's factory state.

When it meets reality of course is that there seem to be a bunch of
variants that seem like pretty compelling use cases.

reset the whole device being one of them.

the specification of a factory-default datastore and then

   o  startup configuration datastore

   o  candiate configuration datastore

   o  running configuration datastore

actually sound a bit implementation specific though I recognize that
most network operating systems due tend to follow models that at least
superficially resembled that.

I'm generally sympathetic to the application the draft proposes.

>
> Joe
>
> ___
> 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] Adoption poll for draft-wu-netmod-factory-default-02

[Alex Campbell]

Support.



From: netmod  on behalf of Kent Watsen 

Sent: Tuesday, 26 March 2019 9:34 a.m.
To: netmod@ietf.org
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

This email begins a 2-week adoption poll for:

https://tools.ietf.org/html/draft-wu-netmod-factory-default-02

Please voice your support or objections before April 8.

Kent (and Lou)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06

[Alex Campbell]

In that case, why not make it so the tags are actually valid URIs, similar to 
XML namespaces?



From: netmod  on behalf of William Lupton 

Sent: Friday, 8 March 2019 7:37 a.m.
To: Andy Bierman
Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; NetMod WG; 
General Area Review Team; draft-ietf-netmod-module-tags@ietf.org
Subject: Re: [netmod] Genart last call review of 
draft-ietf-netmod-module-tags-06

This remark might be out of context (I haven't been following the details) but 
this reference to prefixes makes me wonder whether there's any way that 
registered URN namespaces could be regarded as valid prefixes. 
https://www..iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

On Thu, 7 Mar 2019 at 18:28, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:


On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:
Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies 
> mailto:ietf-secretariat-re...@ietf.org>> 
> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
.
> If I read correctly, the YANG definition in s4.2 REQUIRES that all tags have a
> prefix.  For clarity, it would better if this read:
>All tags MUST begin with a prefix; it is intended that this prefix SHOULD
>   [or maybe 'should'] indicate
>  the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of tags, 
users should be free to do whatever they want and not have implementations or 
standards superfluously block them from doing so. How about we carry the SHOULD 
into the typedef in the YANG model as well? That seems reasonable to me, i.e.,

  typedef tag {
type string {
  length "1..max";
  pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
}
description
  "A tag is a type 'string' value that does not include carriage
   return, newline or tab characters. It SHOULD begin with a
   standard prefix.";




I strongly agree that a prefix SHOULD be present, not MUST be present.
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix "vendor:"
seems a bit short-sighted)


Andy

> S2, para 1: s/yang type/YANG type/ (I think)
>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also be 
> Section
> 2.1. Thus, new modules can drive the addition of new standard tags to the IANA
> registry, and the IANA registry can serve as a check against duplication.
>
> NEW:
> If the module is defined in an IETF standards track document, the tags MUST 
> use
> the prefix defined in Section 2.1. Thus, definitions of new modules can drive
> the addition of new standard tags to the IANA registry defined in Section 7.2,
> and the IANA registry can serve as a check against duplication.
>
> ENDS
>
> S3.2: s/standard/IETF Standard/
>
> S3.3: It would be useful to introduce the term 'masking' used later in the 
> YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =masked-tag= entry for
a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer to RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
> ___
> 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 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] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05

[Alex Campbell]

Hi,


By my understanding both annotations should be included in one JSON object, 
like this.

{
"example:interface" : [
   {
   "name" : "eth1",
   "mtu" : 1500,
   "@mtu" : {
  "ietf-netconf-with-defaults:default" : true,
  "ietf-origin:origin" : "intended"
},
"status" : "up"
  }
  ]
}




From: netmod  on behalf of Amar Jadagoud 

Sent: Thursday, 14 February 2019 7:49 p.m.
To: netmod@ietf.org
Subject: [netmod] Regarding origin annotation encoding in 
ietf-netconf-nmda-restconf-05

Hi All,

I have a question regarding encoding of origin annotation along with other 
annotation (with-defaults) in JSON metadata encoding format.

Suppose if below is the GET method :

GET 
/restconf/ds/ietf-datastores:operational/ietf-interface:interfaces/interface=eth1?with-defaults=report-all-tagged&with-origin
 HTTP/1.1

How both origin and with-defaults annotations should be encoded in the JSON 
metadata encoding format?

Currently in restconf RFC 8040, in section 5.3.2, example with only one 
annotation is provided.

 Refering to this example, whether multiple annotation representation should be 
like below?

{
"example:interface" : [
   {
   "name" : "eth1",
   "mtu" : 1500,
   "@mtu" : {
  "ietf-netconf-with-defaults:default" : true
  },
  {
"ietf-origin:origin" : intended
  },
  "status" : "up"
  }
  ]
}

Thanks,
Amar
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

[Alex Campbell]

Does a percentage really need a single standard type in the first place? How 
about "units percent;"?


From: netmod  on behalf of Acee Lindem (acee) 

Sent: Wednesday, 14 November 2018 5:03 a.m.
To: Juergen Schoenwaelder; Balázs Lengyel
Cc: NETMOD WG
Subject: Re: [netmod] for a future rfc6991bis

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> Hello,
>
> In some cases I want a percentage without fractions. This could be defined
> using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the 
range's
> argument.
>
> typedef percent-short {
>   type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out 
all the 101 integer values :-)
> }
>

I guess we need to settle on a small number of percentage types that
people find useful and then module authors hopefully find what they
need. I am not sure that listing 101 numbers is a good pattern to use
(although it does achieve what you want). For percentages that have no
fraction, you likely want to derive from a base type that is efficient
to encode for binary encodings such as CBOR.

Or simply define a type with a base type of unit8 type and a range of 0-100.

Acee





/js

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


___
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] Confirming draft-ietf-netmod-module-tags-03 consensus call

[Alex Campbell]

Hi,

I was not at the IETF meeting unfortunately.

I see that the technical issues raised in the WGLC have been fixed, which is 
good.

However I still have reservations about the utility of the proposed standard. 
It seems to me like a solution in search of a problem, and I can't understand 
why it should be pushed forward to an RFC. Maybe there is some context I am 
missing. The use-cases that have been described to me so far seem like they 
would be better served by a client-side mechanism. Perhaps the client-side data 
store can still be modelled in YANG, but in that case, I think the document 
should say so.

I asked why the server should hold the data. The reason I am given is "so that 
clients can read it." Why is the data not on the client in the first place?
The client can make modifications to the data, so that the client can read it 
back later. Why does the client need to store these modifications outside of 
itself?

I am told this is a general-purpose tool. In that case, I would like to see at 
least two or three separate use-cases so that I can be sure this is actually a 
*useful general-purpose abstraction*, and not something specific to the one (or 
zero!) use-cases the authors seem to envision. I am aware that the cost of 
creating bad standards can be quite high, if the next person who wants some 
YANG module metadata feels obligated to use the existing tag mechanism instead 
of something new, but finds it doesn't quite fit their needs. See also 
https://blog.codinghorror.com/rule-of-three/ and 
https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

I think the draft could also do with describing how this module is supposed to 
be used. A YANG module in isolation means nothing. Most of the YANG modules I 
am familiar with are to define configuration and/or state data to be stored on 
a network element or a provisioning/orchestration system, and accessed over 
NETCONF. I believe it is implicit that unless otherwise specified, YANG modules 
are intended for NETCONF use, but I am unclear on which kinds of NETCONF 
servers should implement this module.

Perhaps my opinion also carries less weight, as someone who's only on the 
mailing list and didn't actually attend the IETF meeting.




From: netmod  on behalf of joel jaeggli 

Sent: Tuesday, 13 November 2018 5:46 a.m.
To: NETMOD Working Group
Subject: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

During the Thursday nov 8 session of netmod, we asked if there were any 
objections to the publication of the Draft-03 version of 
draft-ietf-netmod-module-tags which addresses comments and concerns raised 
during the WGLC. In the meeting there were none. This commences a comment 
period to confirm that call. As this follows closely on the heels of the IETF 
103 meeting we’ll let the call run through Monday the 26th of November.

https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt


Thanks
Joel
___
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] EXTERNAL: Re: WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Alex Campbell]

Capabilities, features and deviations indicate the type of requests the router 
can respond to.

The capability advertisement may not affect the router, but the capability 
itself directly does.
The capability advertisement tells the client that the router can answer 
requests involving the capability in question.

Will clients base their behaviour on module tags, such as fetching all modules 
with a particular tag?
In that case, as a vendor, I do not understand the implications of adding or 
removing a tag and I would prefer if the RFC was clearer on that point.


From: Christian Hopps 
Sent: Thursday, 18 October 2018 11:16 p.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: EXTERNAL: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 
10/2/18 - 10/16/18

A router has no use for it's capability/feature/deviation advertisements 
either; module-tags are no different in this respect.

Thanks,
Chris.

Alex Campbell  writes:

> Hi,
>
>> The server implements the tags (at least the predefined ones), and the use 
>> cases that come to my mind at least involve clients not servers.
>
> I assume that the server here is a network element implementing 
> ietf-module-tags.
>
> I still don't see why network elements should implement ietf-module-tags.
> What benefit is gained from storing the tags on the server instead of the 
> client? It seems backwards.
>
> Have I misunderstood? I assumed that ietf-module-tags was meant to be 
> implemented by network elements that are NETCONF servers - but now I see the 
> document doesn't actually specify who is meant to implement the module. Your 
> comment about newly installed routers supports my understanding however.
>
>> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to 
>> modules is exactly the point of pre-defined tags, but you questioned their 
>> value at the top of your mail.
>
> The problem with pre-defined tags is that they are never complete. I can 
> always find a useful tag that is not pre-defined.
>
>> Either way configuring a newly installed router is a given, I don't think 
>> this is the place to solve the "forgot to add all the config to my new 
>> router install" issue. :) If one is using tags in ones network then making 
>> sure the newly installed router has tags configured the way you expect is no 
>> different from making sure that you configured IS-IS correctly.
>
> The reason I find this problematic is the same as above - that the router has 
> no use for the tag data.
> It's as if my PC were to download its keyboard mapping table from my home 
> router. Then I change ISPs and have to swap the router, and suddenly my 
> keyboard doesn't work correctly.
> It would be much better to store the keyboard mapping table for my PC *on my 
> PC* instead of adding needless external dependencies.
>
> Alex
>
>
> 
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 9:56 p.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
> 10/16/18
>
> The point is to keep this open to however the community might end up choosing 
> to use it. The act of pre-defining tags doesn't disallow other tags being 
> defined, in fact at this point I've sent a bunch of email defending leaving 
> things as open as possible. They both can co-exist. :)
>
> Thanks,
> Chris.
>
>> On Oct 16, 2018, at 7:32 PM, Alex Campbell  
>> wrote:
>>
>> I have no issue with systems using tags to classify or organize modules, 
>> however this seems to me like something that would be specific to the system 
>> doing the classifying.
>
> Sure we support this. That's what user tag configuration is there for.
>
>> It would not be something that needs to be specified in the module itself 
>> (except perhaps as freeform description text), and it certainly would not 
>> need to involve the NETCONF server.
>> What would a server do with module classification data? (unless it is also 
>> implementing some kind of module browsing interface, in which case it might 
>> be used to supply the browser with data)
>
> The server implements the tags (at least the predefined ones), and the use 
> cases that come to my mind at least involve clients not servers. I'm not 
> saying there wouldn't be a server use case, but it's not as obvious to me.
>
> And yes implementing some kind of module browsing interface (which could 
> group modules by tags) is a fine example of how tags can be used.
>
>

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Alex Campbell]

It means if the model has a node such as:


leaf some-feature {

when "../type = 'ipv4' or ../type = 'ipv6'";

type int32;

}


and a certain device doesn't supports this on IPv6, it is not possible for a 
deviation to change the condition to "../type = 'ipv4'"


Is that intentional? It seems more like an omission to me.



From: Andy Bierman 
Sent: Thursday, 18 October 2018 10:54 a.m.
To: Alex Campbell
Cc: Michael Rehder; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell 
mailto:alex.campb...@aviatnet.com>> wrote:

> At the abstract level I do not understand how when-stmt would work 
> differently.

> IMO deviation-stmt already allows enough flexibility to rewrite the model to
> fit the implementation.

FWIW: deviation statements cannot be used to modify when statements - "when" is 
missing from the list of statements that can be added/removed/replaced..
I'm wondering if this should be considered errata.



This was intentional.
I meant that deviations can already be used to add/replace/remove constraints 
within data nodes.
It is true that there is no way to say certain constraints only apply based on 
external data.
As Robert said, I don't understand why we need that.


Andy


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
That's exactly my point - I think that the wording is unclear in the RFC, that 
"conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at 
least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect 
mandatory status or not by a when statement.



The when statement works as intended. The entire subtree is on or off if 
when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1 
section, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer to
say "this part of the model is only relevant for a subset of all possible values
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work differently.
IMO deviation-stmt already allows enough flexibility to rewrite the model to
fit the implementation.



Thanks
mike

Andy

> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz<mailto:lho...@nic.cz>]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder ; Juergen Schoenwaelder
> mailto:j.schoenwael...@jacobs-university.de>>
> Cc: netmod@ietf.org<mailto:netmod@ietf.org>
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael Rehder  writes:
>
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
>
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is closely
> related to sec. 3.1 in 6020.
>
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
>
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
>
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
>
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert..
>
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that a

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Alex Campbell]

Hi,

> The server implements the tags (at least the predefined ones), and the use 
> cases that come to my mind at least involve clients not servers.

I assume that the server here is a network element implementing 
ietf-module-tags.

I still don't see why network elements should implement ietf-module-tags.
What benefit is gained from storing the tags on the server instead of the 
client? It seems backwards.

Have I misunderstood? I assumed that ietf-module-tags was meant to be 
implemented by network elements that are NETCONF servers - but now I see the 
document doesn't actually specify who is meant to implement the module. Your 
comment about newly installed routers supports my understanding however.

> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to 
> modules is exactly the point of pre-defined tags, but you questioned their 
> value at the top of your mail.

The problem with pre-defined tags is that they are never complete. I can always 
find a useful tag that is not pre-defined.

> Either way configuring a newly installed router is a given, I don't think 
> this is the place to solve the "forgot to add all the config to my new router 
> install" issue. :) If one is using tags in ones network then making sure the 
> newly installed router has tags configured the way you expect is no different 
> from making sure that you configured IS-IS correctly.

The reason I find this problematic is the same as above - that the router has 
no use for the tag data.
It's as if my PC were to download its keyboard mapping table from my home 
router. Then I change ISPs and have to swap the router, and suddenly my 
keyboard doesn't work correctly.
It would be much better to store the keyboard mapping table for my PC *on my 
PC* instead of adding needless external dependencies.

Alex


____
From: Christian Hopps 
Sent: Wednesday, 17 October 2018 9:56 p.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
10/16/18

The point is to keep this open to however the community might end up choosing 
to use it. The act of pre-defining tags doesn't disallow other tags being 
defined, in fact at this point I've sent a bunch of email defending leaving 
things as open as possible. They both can co-exist. :)

Thanks,
Chris.

> On Oct 16, 2018, at 7:32 PM, Alex Campbell  wrote:
>
> I have no issue with systems using tags to classify or organize modules, 
> however this seems to me like something that would be specific to the system 
> doing the classifying.

Sure we support this. That's what user tag configuration is there for.

> It would not be something that needs to be specified in the module itself 
> (except perhaps as freeform description text), and it certainly would not 
> need to involve the NETCONF server.
> What would a server do with module classification data? (unless it is also 
> implementing some kind of module browsing interface, in which case it might 
> be used to supply the browser with data)

The server implements the tags (at least the predefined ones), and the use 
cases that come to my mind at least involve clients not servers. I'm not saying 
there wouldn't be a server use case, but it's not as obvious to me.

And yes implementing some kind of module browsing interface (which could group 
modules by tags) is a fine example of how tags can be used.

>
> Hashtags - all types, that I'm aware of - are inherently freeform and fluid, 
> changing quickly according to the desires of users. I don't think it makes 
> sense to "hard-code" them in published RFCs or even published vendor modules 
> or firmware.
>
> Tomorrow, I might want to list all modules for management plane protocols. As 
> a network operator, should I go and update the ietf-module-tags on all of my 
> network elements? That seems silly. This should be client-side data. (And if 
> I did, what happens when I add a new router and forget to update its tag 
> data? Will that confuse the client?)

I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules 
is exactly the point of pre-defined tags, but you questioned their value at the 
top of your mail.

Either way configuring a newly installed router is a given, I don't think this 
is the place to solve the "forgot to add all the config to my new router 
install" issue. :) If one is using tags in ones network then making sure the 
newly installed router has tags configured the way you expect is no different 
from making sure that you configured IS-IS correctly.

Thanks,
Chris.

>
> Regards, Alex
>
> 
> From: Christian Hopps 
> Sent: Wednesday, 17 

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Alex Campbell]

> At the abstract level I do not understand how when-stmt would work 
> differently.

> IMO deviation-stmt already allows enough flexibility to rewrite the model to
> fit the implementation.

FWIW: deviation statements cannot be used to modify when statements - "when" is 
missing from the list of statements that can be added/removed/replaced..
I'm wondering if this should be considered errata.



From: netmod  on behalf of Andy Bierman 

Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
Cc: netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
That's exactly my point - I think that the wording is unclear in the RFC, that 
"conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at 
least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect 
mandatory status or not by a when statement.



The when statement works as intended. The entire subtree is on or off if 
when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1 
section, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer to
say "this part of the model is only relevant for a subset of all possible values
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work differently.
IMO deviation-stmt already allows enough flexibility to rewrite the model to
fit the implementation.



Thanks
mike

Andy

> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder ; Juergen Schoenwaelder
> mailto:j.schoenwael...@jacobs-university.de>>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael Rehder  writes:
>
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
>
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is closely
> related to sec. 3.1 in 6020.
>
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
>
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
>
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
>
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert..
>
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that are present in
>   the instance document.
>
> >
> > I still think that the YANG RFC wording of "conditional" needs to indicate 
> > if the
> node is mandatory status is affected or not.
> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > does mention presence).
>
> Perhaps this thread is just about misunderstanding of what "when" really
> means, which is: Instances for which the "when" expression evaluates to false
> must not be present.
>
> It does NOT mean that instances for which the "when" expression evaluates to
> true must be present.
>
> Lada
>
> >
> > Thanks
> > Mike
> >> -Original Message-
> >> From: Juergen Schoenwaelder
> >> [mailto:j.schoenwael...@jacobs-university.de]
> >> Sent: Saturday, October 13, 2018 5:20 PM
> >> To: Michael Rehder 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> >> ensure presence of the mandatory object
> >>
> >> On Fri, Oct 12, 2018 at 04:08:48PM +, Michael Rehder wrote:
> >>
> >> > The mandatory statement in that case is ignored (I've pointed out
> >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
> >> > mandatory status (via explicit mandatory or implicit mandatory via
> >> > min-elements
> >> > 1)
> >>
> >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> >> this may be a problem with RFC 6110 but not with YANG itself

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Alex Campbell]

I have no issue with systems using tags to classify or organize modules, 
however this seems to me like something that would be specific to the system 
doing the classifying.
It would not be something that needs to be specified in the module itself 
(except perhaps as freeform description text), and it certainly would not need 
to involve the NETCONF server.
What would a server do with module classification data? (unless it is also 
implementing some kind of module browsing interface, in which case it might be 
used to supply the browser with data)

Hashtags - all types, that I'm aware of - are inherently freeform and fluid, 
changing quickly according to the desires of users. I don't think it makes 
sense to "hard-code" them in published RFCs or even published vendor modules or 
firmware.

Tomorrow, I might want to list all modules for management plane protocols. As a 
network operator, should I go and update the ietf-module-tags on all of my 
network elements? That seems silly. This should be client-side data. (And if I 
did, what happens when I add a new router and forget to update its tag data? 
Will that confuse the client?)

Regards, Alex


From: Christian Hopps 
Sent: Wednesday, 17 October 2018 1:04 a.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
10/16/18

>
> On Oct 3, 2018, at 8:22 PM, Alex Campbell  wrote:
>
> The introduction does not explain what they are useful for

The second sentence of the abstract: "The expectation is for such tags to be 
used to help classify and organize modules." The introduction repeats this in 
the first sentence. I'm not sure how much differently we could say "Tags are 
useful for organizing and classifying modules". Are you asking for 
justification on the usefulness of organizing and classifying things? I think 
this concept is rather widely accepted.


> , it just makes a comparison to #hashtags (which is something I would expect 
> to see in an April 1st RFC).

Using tags to help organize collections of data is literally ubiquitous: 
Movies/music/media, IP routes, and yes even social media are just a few 
examples.  Regarding April 1st, are you are unfairly restricting your 
perspective to only the ironic use of hashtags? Hashtags organically developed 
as a useful and widely used way for people and groups to add meta-data to their 
messages which then allowed other services to collect and present them in 
useful ways. Indeed businesses and other groups use hashtags for this purpose 
to great success. It was hardly a joke, and for many folks it is immediately 
useful to understand what is being proposed.

Thanks,
Chris.

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

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Alex Campbell]

Do not support.

This document does not make a good case for why tags should exist.
The introduction does not explain what they are useful for, it just makes a 
comparison to #hashtags (which is something I would expect to see in an April 
1st RFC).
The initial registry values, section 8.2, also provide no insight as to the 
value of any of these tags. At best these values could be used to categorise 
modules for human browsing.

In short, I see no evidence that the standard this document attempts to define 
is actually useful.



Additional major concerns:
- the draft does not indicate who should implement the included YANG module.
- there is no automatic mechanism specified (such as an extension statement) by 
which the server can read the tags from the module (as 4.1 specifies must 
happen), therefore the implementer will have to do this manually and is likely 
to forget.
- I do not believe servers should be concerned with classifying their 
implemented YANG modules, unless there is a good reason. This seems like a 
client responsibility. How will the system work in a large network with one 
client reading data from 500 servers, each of which could have different tag 
data? Or maybe two clients with different tag data, both trying to update the 
network to hold the "correct" data.





From: netmod  on behalf of joel jaeggli 

Sent: Wednesday, 3 October 2018 9:21 a.m.
To: NETMOD Working Group
Subject: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

This is start of a two week working group last-call for
draft-ietf-netmod-module-tags-02 a current netmod working group
document.

You may review at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

The prior discussion of my mistaken WG adoption call is here

commences here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html

In particular Andy's concerns expressed in that thread here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html

are probably important to tease out in considering this for last call.

so that we are clear on dates. This last call timing resets and runs
from 10/2/18 - 10/16/18

Joel


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

Re: [netmod] EXTERNAL: Module update rules: changing a type to a union

[Alex Campbell]

Hi,


It seems to be that the rule you quoted specifically states that expanding the 
value space is not okay:


   o  A "type" statement may be replaced with another "type" statement
  that does not change the syntax or semantics of the type.  For
  example, an inline type definition may be replaced with a typedef,
  but an int8 type cannot be replaced by an int16, since the syntax
  would change.




From: netmod  on behalf of Sterne, Jason (Nokia - 
CA/Ottawa) 
Sent: Saturday, 11 August 2018 3:19 a.m.
To: netmod@ietf.org
Subject: EXTERNAL: [netmod] Module update rules: changing a type to a union

Hi all,

I'm uncertain about how to interpret the YANG module update rules when a type 
changes to a union.

Is the following change allowed?

From:
  typedef my-type {
type enumeration {
  enum "foo";
}
  }
To:
  typedef my-type {
type union {
  type enumeration {
enum "foo";
  }
  type uint32;
}
  }

The general spirit of the rules is that expanding the value space is generally 
OK, but this case does seem to violate this paragraph of section 11:

   o  A "type" statement may be replaced with another "type" statement
  that does not change the syntax or semantics of the type.  For
  example, an inline type definition may be replaced with a typedef,
  but an int8 type cannot be replaced by an int16, since the syntax
  would change.


Does the addition of the union change the semantics of the type if that union 
encompasses the original type?

With XML encoding I can see how an "old" client could easily still communicate 
with a "new" server for this change. But I wonder about other possible 
encodings that might change when a type becomes a union that contains 
additional types.

Regards,
Jason
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] three questions about YANG deviation statement

[Alex Campbell]

Hi,


[Note I haven't tested these answers. Also this is a source level view, with no 
regards for compatibility]


[1] If you want to make a node optional (not mandatory), the way to do that is:

  deviation "/a:a" {

deviate replace {

  mandatory false;

}

  }


[2] Deviation statements can replace types arbitrarily. Example:

  deviation "/a:a" {

deviate replace {

  type uint8 {

range "1..100";

  }

}

  }

The whole type is replaced, there isn't a way to replace just the range.


[3] Based on RFC 7950 section 5.4, it looks like your YANG is correct. If some 
tools cannot process the module it is a bug in the tool.

However as a workaround, you could always define the type inline without a 
typedef.

Perhaps also try 'type md:date-and-time;' (i.e. add the prefix for the 
deviation module)


I think your leafref problem is related. It seems that the tool is searching 
for prefixes imported in the target module, which is not correct according to 
the RFC.




From: netmod  on behalf of Zhengguangying (Walker) 

Sent: Wednesday, 11 July 2018 3:05 p.m.
To: netmod@ietf.org; Yangang (Routing Design); Yangshouchuan; Qudan 
(Beijing-NOS); Qin Wu
Subject: [netmod] three questions about YANG deviation statement

Hi all,
   When we try to implementing, there are 3 questions want to clear on WG, 
please expert help to answer the questions, thanks.


[Question 1]: whether "mandatory true" node can be deviated as "not-supported" ?

[Question 2]: Whether can deviation YANG to expand the range of type?

   example:

 target YANG node:
 leaf a {
  type uint 8 {
range "1..50";
  }
}

deviation yang:

deviation "/a:a" {
  replace type {
range "1..100";
  }
}


[Question 3]: How to use a new type defined by "typedef" to deviate replace the 
target module's type.

example:
module example-base {
  namespace "urn:example-base";
  prefix base;

  container system {
description
 "System group configuration.";
leaf daytime {
   type string;
}
leaf date {
   type string;
}
leaf interface {
   type string;
}
leaf status {
   type string;
   config false;
}
  }
}

module example-deviations {
   yang-version 1.1;
   namespace "urn:example:deviations";
   prefix md;

   import example-base {
 prefix base;
   }

   import ietf-interfaces {
 prefix if;
   }

   // here, define a new type with typedef statement
   typedef date-and-time {
 type string {
   pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
 + '(Z|[\+\-]\d{2}:\d{2})';
 }
}

   // try to replace the target node's type with new typedef type
   deviation /base:system/base:date {
 deviate replace {
type date-and-time;
 }
   }

deviation /base:system/base:interface {
 deviate replace {
type leafref {
path "/if:interfaces/if:interface/if:name";
}  }
   }
   ...
 }


problem 1: when use new type defined in deviation YANG file to replace the 
target node's type, some tools give compile error, because they can not find 
the definition of new type "date-and-time" . From the YANG language view, this 
error looks reasonable, but how to replace the target node with newly deifned 
type?

problem 2: when try to replace the type to leafref a xpath which not imported 
in the target module, it have the compile error too, then how to replace the 
target node with another module's xpath?


Thanks
Walker(Guangying zheng)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] EXTERNAL: Re: New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt

[Alex Campbell]

Hi Bo,

My comments: (ignoring simple typos and placeholder values as this is a first 
draft)

* What is a TACACS+ template? To my knowledge this is not a standard concept. 
The word "template" does not appear in draft-ietf-opsawg-tacacs-10.
* What is a domain name, in the context of usernames? "domain" also does not 
appear in draft-ietf-opsawg-tacacs-10.
* I don't think ipv4-address-no-zone should be used by default, unless there is 
a good reason to prohibit the use of zones.
  Systems that do not implement zones can reject addresses containing zones; 
but some systems may require zones.
* This module seems to imply a particular server selection algorithm (with the 
use of primary/secondary and current servers). What is the algorithm?
  Our TACACS+ code does not have a concept of a primary, secondary or current 
server. It has a prioritized list of servers, and tries each request towards 
each server in turn until it receives a pass or fail response (as opposed to an 
error). The assumption in this design is that servers are up most of the time.
* Many of the leaves seem unnecessary and not terribly useful.
  For example, sec-author-srv-num (Total number of configured secondary 
authorization servers in the template).
  Is this value needed so frequently that it needs to be available as a 
separate value - instead of having the management client simply read the whole 
list of servers, and count how many are secondary and used for authentication?
* What is the public net?
* Why is there a maximum of 32 servers?
* There should not need to be separate lists for ipv4 and ipv6 servers. I see 
that ipv6 servers don't support public-net, so I'll reserve judgement until I 
find out what public-net does.
* What should implementations do if they don't support ietf-network-instance?

As a related side note, I'd really like to see a standard for TACACS+ over TLS.

Regards,
Alex

From: netmod  on behalf of Wubo (lana) 

Sent: Monday, 2 July 2018 8:07 p.m.
To: netmod@ietf.org; ops...@ietf.org
Subject: EXTERNAL: Re: [netmod] New Version Notification for 
draft-zheng-netmod-tacacs-yang-01.txt

Dear Netmod, Opsawg,

Please see our newly uploaded draft of TACACS+ YANG data model, which can be 
found at
https://www.ietf.org/internet-drafts/draft-zheng-netmod-tacacs-yang-01.txt.


This data model draft is based on the TACACS+ working group draft - 
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-10.
TACACS+ provides Device  Administration for routers, network access servers and 
other  networked computing devices via one or more
centralized servers.  With various TACACS+ Implementation, service provider may 
need different TACACS+ YANG modules
 to manipulate massive devices.
So we propose to define a  generic TACACS+ data model  to alleviate this issue.

We are looking forward to receiving your response.

Best regards.

Bo


-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
发送时间: 2018年7月2日 14:15
收件人: wangzitao ; Wubo (lana) ; 
Zhengguangying (Walker) ; Wubo (lana) 
; wangzitao 
主题: New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt


A new version of I-D, draft-zheng-netmod-tacacs-yang-01.txt
has been successfully submitted by Bo Wu and posted to the IETF repository.

Name:   draft-zheng-netmod-tacacs-yang
Revision:   01
Title:  Yang data model for Terminal Access Controller Access Control 
System Plus
Document date:  2018-07-01
Group:  Individual Submission
Pages:  33
URL:
https://www.ietf.org/internet-drafts/draft-zheng-netmod-tacacs-yang-01.txt
Status: https://datatracker.ietf.org/doc/draft-zheng-netmod-tacacs-yang/
Htmlized:   https://tools.ietf.org/html/draft-zheng-netmod-tacacs-yang-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-zheng-netmod-tacacs-yang
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-zheng-netmod-tacacs-yang-01

Abstract:
   This document describes a data model of Terminal Access Controller
   Access Control System Plus (TACACS+).

   The YANG data model in this document conforms to the Network
   Management Datastore Architecture (NMDA) defined in [RFC8342].




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.

The IETF Secretariat

___
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] leaf-list in YANG 1.1

[Alex Campbell]

As far as I'm aware, state values are not writable by the client, so the 
question is moot.


Regards, Alex



From: netmod  on behalf of Bogaert, Bart (Nokia - 
BE/Antwerp) 
Sent: Tuesday, 29 May 2018 12:56 p.m.
To: netmod@ietf.org
Subject: [netmod] leaf-list in YANG 1.1

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi,

We have a question about the leaf-list in config-false data.  When comparing 
YANG 1.0 and YANG 1.1 the restriction on having unique values seems to have 
been lifted for config-false data:

  *   Section 7.7 RFC 7950: "In configuration data, the values in a leaf-list 
MUST be unique."
  *   Section 7.7 RFC 6020: "The values in a leaf-list MUST be unique.")

This means one can have multiple entries with the same value in a state 
leaf-list.  What is expected to happen when you delete an entry by specifying 
the value of the leaf-list entry and there happen to be multiple entries with 
the same value? Are all these entries deleted or is one expected to perform as 
many delete operations as there are entries matching the value specified in the 
delete operation?

Regards, Bart
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Clarification about subtree filtering

[Alex Campbell]

Hi,


Since nobody else has answered I'll have a go.

I'm not familiar with subtree filtering, but I am with XPath. Assuming your 
XPath translation is accurate, it will return no data (response A).



From: netmod  on behalf of Shiva Kumar Pathori 

Sent: Tuesday, 22 May 2018 8:38 p.m.
To: netmod@ietf.org
Subject: [netmod] Clarification about subtree filtering


Hi,
Can somebody clarify what could be the response for the  operation 
provided below.

Following is the user information in the datastore that is provided in the RFC 
6241 as example.

   
 
   
 
 
   http://example.com/schema/1.2/config";>
 
   
 
   
 


  
http://example.com/schema/1.2/config";>
  

  root
  superuser
  Charlie Root
  
1
1
  


  fred
  admin
  Fred Flintstone
  
2
2
  


  barney
  admin
  Barney Rubble
  
2
3
  

  

  



The  operation with content-match at parent and child nodes;


  

  


  http://example.com/schema/1.2/config";>

  
admin

  1

  

  

  


The equivalent XPATH expression :

  

  

http://example.com/schema/1.2/config";
 type="xpath"
 
select="/t:top/t:users/t:user[t:type='admin']/t:company-info[t:dept='1']"/>

 

For this what could be the response

a) The response based on content-match nodes are AND-ed together

   
  
 
OR

b)  The response based on content-match nodes treated separately

  
http://example.com/schema/1.2/config";>
  

  fred
  admin
  Fred Flintstone


  barney
  admin
  Barney Rubble

  

  


Regards,
Shiva



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

Re: [netmod] An abundant amount of IANA if types...

[Alex Campbell]

I haven't seen any previous discussions on the topic, but we have a similar 
problem.

Note this is not really to do with YANG itself, so much as the practical 
limitations of the software package that provides our CLI interface.

In NETCONF, the existence of extra unused identities doesn't pose any problem.



From: netmod  on behalf of Bogaert, Bart (Nokia - 
BE/Antwerp) 
Sent: Thursday, 5 April 2018 8:21 p.m.
To: netmod@ietf.org
Subject: [netmod] An abundant amount of IANA if types...

Hi,

We were wondering if it would make sense to introduce features in the IANA if 
types YANG model to enable grouping of related interface types.  This would 
allow implementations to include only the types it really requires (by 
supporting the related features but not the others) and (in case of a CLI 
interface) would reduce the possible completions if an operator would ask for 
the possible values of the type of an interface.
Has this ever been considered/discussed?

Best regards,
Bart
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 'must' Xpaths, predicates and wildcards

[Alex Campbell]

Hi Jason,


In that case I would just use must "../a-list" - or optionally must 
"count(.../a-list) > 0"; if you're concerned readers might not understand the 
former.


Regards,

  Alex

(Am I the only one who feels these signatures are silly?)



From: Sterne, Jason (Nokia - CA/Ottawa) 
Sent: Thursday, 29 March 2018 5:11 a.m.
To: Alex Campbell; netmod@ietf.org
Subject: RE: YANG 'must' Xpaths, predicates and wildcards

Thanks Alex.  Sorry about those sloppy mistakes.  I agree about the ../a-list 
and I should have said count > 0.

In the 2nd part of my email, my intention was to only allow foo to be 
configured if a-list has at least one entry configured.   So I don't think 
min-elements 1 would work.  I don't want to always require an entry in a-list.  
I only want to require one if foo is configured.

I guess this also achieves the same thing right ?
  must "../a-list[entry=*]";

If foo has a default value, then does that mean the "must" is evaluated even if 
foo is deleted from the config ?
leaf foo {
  must "../a-list";   <- always evaluated because of default ?
  type uint16;
  default 5;
}
If the must is always evaluated then it would be the equivalent of having 
min-elements 1 in a-list.

Rgds,
Jason

From: Alex Campbell [mailto:alex.campb...@aviatnet.com]
Sent: Tuesday, March 27, 2018 9:57 PM
To: Sterne, Jason (Nokia - CA/Ottawa) ; net...@ietf..org
Subject: Re: YANG 'must' Xpaths, predicates and wildcards


Hi,



For one thing, it should be ../a-list since a-list is not a child of foo.

Also - if foo is not configured and has no default value, then any must 
expressions in foo are not evaluated because it is not part of the "accessible 
tree". (I tested this in ConfD)

Apart from these issues, yes it will behave as you expect - it will fail if 
a-list contains no entries.



must "count(a-list) > 1"; is not equivalent since it requires at least two 
entries.



However, you can more simply add a min-elements 1; statement to a-list to 
achieve the same goal - no XPath required.




From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Sterne, Jason (Nokia - CA/Ottawa) 
mailto:jason.ste...@nokia.com>>
Sent: Wednesday, 28 March 2018 1:10 p.m.
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] YANG 'must' Xpaths, predicates and wildcards

Hi all,

I'm pretty sure that this xpath (e.g. in a must statement) isn't correct:

  (A) ../container-a/list-b[name=*]/some-leaf

and should just be this instead:

  (B) ../container-a/list-b/some-leaf

Or is the * an allowable wildcard for a key value in a predicate ?

I also had a question about whether the following "must" correctly checks that 
at least one entry exists in a-list.

  container c1 {
leaf foo {
  must "a-list";
  type uint16;
}
list a-list {
  key "entry";
  leaf entry {
type uint16;
  }
  leaf another-entry {
type uint32;
  }
}
  }

I think I could also replace that must with the following:
  must "count(a-list) > 1";
but does must "a-list"; achieve the same thing ?

Rgds,
Jason
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 'must' Xpaths, predicates and wildcards

[Alex Campbell]

Hi,


For one thing, it should be ../a-list since a-list is not a child of foo.

Also - if foo is not configured and has no default value, then any must 
expressions in foo are not evaluated because it is not part of the "accessible 
tree". (I tested this in ConfD)

Apart from these issues, yes it will behave as you expect - it will fail if 
a-list contains no entries.


must "count(a-list) > 1"; is not equivalent since it requires at least two 
entries.


However, you can more simply add a min-elements 1; statement to a-list to 
achieve the same goal - no XPath required.



From: netmod  on behalf of Sterne, Jason (Nokia - 
CA/Ottawa) 
Sent: Wednesday, 28 March 2018 1:10 p.m.
To: netmod@ietf.org
Subject: [netmod] YANG 'must' Xpaths, predicates and wildcards

Hi all,

I'm pretty sure that this xpath (e.g. in a must statement) isn't correct:

  (A) ../container-a/list-b[name=*]/some-leaf

and should just be this instead:

  (B) ../container-a/list-b/some-leaf

Or is the * an allowable wildcard for a key value in a predicate ?

I also had a question about whether the following "must" correctly checks that 
at least one entry exists in a-list.

  container c1 {
leaf foo {
  must "a-list";
  type uint16;
}
list a-list {
  key "entry";
  leaf entry {
type uint16;
  }
  leaf another-entry {
type uint32;
  }
}
  }

I think I could also replace that must with the following:
  must "count(a-list) > 1";
but does must "a-list"; achieve the same thing ?

Rgds,
Jason
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] sub-intf-vlan-model for VLAN forwarding

[Alex Campbell]

Hi,


I'm currently looking at draft-ietf-netmod-sub-intf-vlan-model-03 to see 
whether we can use this as our main model for VLAN forwarding, and it appears 
the answer is no.
There is no way to configure forwarding in this model; it is strictly about 
interfaces.


The appendix gives the impression that this model can be used to configure 
forwarding, though: "Both models can be used for configuring similar basic 
layer 2 forwarding topologies,"

Is forwarding configuration out of scope of this model?


Thanks,

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

Re: [netmod] Guideline on modeling including features and phased support by a device

[Alex Campbell]

Presumably you will have to decide on a sensible default value to use.


What value will your actual device use after the software upgrade? That should 
be the value it stores in the data tree when performing the upgrade.




From: netmod  on behalf of Bogaert, Bart (Nokia - 
BE/Antwerp) 
Sent: Monday, 5 March 2018 10:25 p.m.
To: netmod@ietf.org
Subject: [netmod] Guideline on modeling including features and phased support 
by a device

Hi,

We have a question with respect to YANG models using features.  Assume that a 
part of the model is defined under a feature and that this feature-dependent 
part defines a leaf as mandatory.

module servers {
  namespace "http://www.example.com/servers";;
  prefix servers;

  import ietf-inet-types {
prefix inet;
  }

  revision 2018-03-01 {
description
   "Initial version.";
  }

  feature test-feature {
description "testing feature";
  }

  container servers {
list server {
  key name;
  max-elements 64;
  leaf name {
type string;
  }
  leaf ip {
type inet:ip-address;
mandatory true;
  }
  leaf port {
type inet:port-number;
mandatory true;
  }
  leaf only-if-feature {
if-feature test-feature;
type string;
mandatory true;
  }
}
  }
}

Now assume that we have a device that implements the model step-wise by first 
not supporting this feature and in a sub-sequent release by supporting this 
feature (and uses a persistent running datastore).  The question arising now is 
how to deal with this mandatory leaf?  Normally this can only be configured by 
a client, meaning that without any "help", the NC server will not be able to 
startup with the data contained in the device's persistent datastore unless a 
value is set for the mandatory leaf that now becomes available as a result of 
supporting the feature.

When modeling as follows it seems the NC server can start with the model 
supporting the feature that was not supported before:

module servers {
  namespace "http://www.example.com/servers";;
  prefix servers;

  import ietf-inet-types {
prefix inet;
  }

  revision 2018-03-01 {
description
   "Initial version.";
  }

  feature test-feature {
description "testing feature";
  }

  container servers {
list server {
  key name;
  max-elements 64;
  leaf name {
type string;
  }
  leaf ip {
type inet:ip-address;
mandatory true;
  }
  leaf port {
type inet:port-number;
mandatory true;
  }
  container only-if-feature {
presence "see if this helps";
if-feature test-feature;
leaf only-if-feature {
  type string;
  mandatory true;
}
  }
}
  }
}

Are recommendations or guidelines in place to deal with this?

Regards, Bart

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

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

[Alex Campbell]

Hi,

Perhaps not directly relevant, but the following sentence stuck out to me:

> Why not use the syslog/TLS specification, with the security features 
> administratively turned off within secure environments?

I was under the impression that the IETF tries to ensure that TLS security is 
not possible to turn off.
The assumption within the people working on TLS is that if you don't want 
security, you won't be using TLS.


I can think of two main reasons why syslog/TLS might not be desirable
- it adds administrative overhead - now you have to upload a certificate to 
every device that can send log messages (embedded devices don't use the Web's 
PKI).
- it adds runtime overhead - while general purpose devices these days are 
plenty fast to handle TLS, embedded devices may not be.


If TCP support is removed from the syslog model, then Aviat will most likely 
add it back as a vendor-specific extension, when we adopt this model.
I see the model is easily extensible with new transports so this will not be a 
problem - the only question is whether the extension should be standardized.
A quick Google search shows me that (at least some) Cisco and Juniper devices 
do support syslog/TCP, but it isn't widely used compared to UDP.


Alex


From: netmod  on behalf of Kent Watsen 

Sent: Saturday, 10 February 2018 5:42 a.m.
To: t.petch; Clyde Wildes (cwildes); netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Thank you, Tom.  That's an interesting bit of history there.  Of course, you 
would know, as I see you listed in the Acknowledgments section in RFC 6587.  
David Harrington's points are very compelling.

The chairs want to get this draft to Benoit before he steps down.  But looking 
at the draft right now, I can see that it is a very easy fix to remove the TCP 
transport layer support entirely, not much more than just moving the reference 
to Informative.

So, yes, let's bin it.

FWIW, I asked before if it were important to anyone, giving them a chance to 
speak up first.  But now, given how easy I see the fix is, that we should 
remove it without waiting for an answer.  If it is important to someone, let 
them speak up now.

Clyde, please let this be the update you plan to post today.

Thanks,
Kent // all hats


= original message =

Kent

The TCP syslog started out as Standards Track, after the syslog WG had
concluded, but David Harrington objected, as the extract below shows,
that it would never pass the IESG; and so it became Informational.

Further, the author, in 2013, described it as

"there is also historic RFC6587 on industry standard plain tcp, but this
is just for interoperating with legacy systems, not for new
implementation. It is strongly discouraged to use that in new systems.
"

Bin it IMHO.

Tom Petch
==


Many of the changes were made at my request.
I believe the document as written would not have made it through IESG
approval.

1) the IETF has defined a standard syslog; how to make your legacy
proprietary version work is not an IETF problem.

2) the syslog WG was created to develop a secure syslog solution with
secure transport and signing capability.
How to make your legacy proprietary version work over non-secure
transport is not an IETF problem.

3) Publishing this as a proposed standard seems to violate BCP 61.
syslog/tls already provides "strong security" over tcp, so syslog/tcp
is not needed to meet IETF goals. Under what
circumstances is it **desirable** to use this specification (with no
strong security available) in the Internet? Why not use the syslog/TLS

specification, with the security features administratively turned off
within secure environments?
You cannot justify implementing this by saying things like
"syslog/TLS is required and this is optional", and not explain WHY
this
additional non-bcp61-compliant specification is needed.

4) The aim of this IETF specification should be to document "how TCP
MAY be used as a
transport for standardized syslog", when the standard secure transport
may not apply.
(But I expect serious pushback from the IESG on this; see #3)
Because this might have to work with legacy deployments, we also
include as an appendix
"how to correlate the legacy and standard usages."

5) RFC3164 is just a survey, not a specification.

6) RFC2119 language needed to be cleaned up.

David Harrington
Director, IETF Transport Area
ietf...@comcast.net (preferred for ietf)
dbharring...@huaweisymantec.com
+1 603 828 1401 (cell)

> -Original Message-
> From: syslog-boun...@ietf.org
> [mailto:syslog-boun...@ietf.org] On Behalf Of t.petch
> Sent: Tuesday, November 02, 2010 1:02 AM
>
> Chris
>
> I had not noticed before but this seems to have changed
> direction during the
> summer; Informational not Standards Track, and stressing
> byte-counting more,
> byte-stuffing less.
>
> I do find it less clear.  I think that the Introduction needs
> more work in th

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

[Alex Campbell]

Hi,


Good point - adding on to that, I'd like to point out that there are more 
protocols that use ports besides TCP and UDP, such as SCTP and DCCP.
If the port number was not protocol-specific then devices would also have to 
match SCTP ports, DCCP ports, and other protocol ports, even for protocols 
which haven't been invented yet. This is not possible to implement.

> Thus, if a very simple device can understand TCP and UDP ports but cannot 
> understand more detailed information, that is supported.


I don't think YANG features can possibly envision or handle all the potential 
variations between devices, unless we give each criterion its own separate 
feature.

To my knowledge, the device I am currently working on doesn't support port 
range matching, or operators other than 'equals', and I see there is currently 
no YANG feature for that.

Do you think it would be better to let vendors use deviations to indicate which 
features aren't supported?




From: netmod  on behalf of Eliot Lear 
Sent: Tuesday, 23 January 2018 8:14 a.m.
To: Kent Watsen; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15


Hi Kent and Mahesh and Sonal,

Thanks very much for working on this draft.  I have noted one problem that I 
think needs correcting.  I come prepared with a diff.

The current model has {source,dest}-port-or-range hanging off ipv4 or ipv6.  
This is a transport parameter and is not appropriate for protocols that do not 
use ports (ie, ICMP, ESP, etc).  A better locale would be to hang these 
components underneath l4 underneath their respective tcp and udp branches.

Because this is so basic a function, I propose that this not be included in 
match-on-tcp or match-on-udp.  Instead, the contents of both tcp and udp be 
moved to new containers "tcp-all" and "udp-all", respectively, and the ports 
hang as peers to that.  Thus, if a very simple device can understand TCP and 
UDP ports but cannot understand more detailed information, that is supported.

 And so from a tree perspective, it would look like this:


   ||  +--rw (l4)?
   ||  |  +--:(tcp)
   ||  |  |  +--rw tcp
   ||  |  | +--rw source-port-range-or-operator
   ||  |  | |  +--rw (port-range-or-operator)?
   ||  |  | | +--:(range)
   ||  |  | | |  +--rw lower-portinet:port-number
   ||  |  | | |  +--rw upper-portinet:port-number
   ||  |  | | +--:(operator)
   ||  |  | |+--rw operator? operator
   ||  |  | |+--rw port  inet:port-number
   ||  |  | +--rw destination-port-range-or-operator
   ||  |  | |  +--rw (port-range-or-operator)?
   ||  |  | | +--:(range)
   ||  |  | | |  +--rw lower-portinet:port-number
   ||  |  | | |  +--rw upper-portinet:port-number
   ||  |  | | +--:(operator)
   ||  |  | |+--rw operator? operator
   ||  |  | |+--rw port  inet:port-number
   ||  |  | +--rw tcp-all {match-on-tcp}?
   ||  |  |+--rw sequence-number?  uint32
   ||  |  |+--rw acknowledgement-number?   uint32
   ||  |  |+--rw data-offset?  uint8
   ||  |  |+--rw reserved? uint8
   ||  |  |+--rw flags?bits
   ||  |  |+--rw window-size?  uint16
   ||  |  |+--rw urgent-pointer?   uint16
   ||  |  |+--rw options?  uint32
   ||  |  +--:(udp)
   ||  |  |  +--rw udp
   ||  |  | +--rw source-port-range-or-operator
   ||  |  | |  +--rw (port-range-or-operator)?
   ||  |  | | +--:(range)
   ||  |  | | |  +--rw lower-portinet:port-number
   ||  |  | | |  +--rw upper-portinet:port-number
   ||  |  | | +--:(operator)
   ||  |  | |+--rw operator? operator
   ||  |  | |+--rw port  inet:port-number
   ||  |  | +--rw destination-port-range-or-operator
   ||  |  | |  +--rw (port-range-or-operator)?
   ||  |  | | +--:(range)
   ||  |  | | |  +--rw lower-portinet:port-number
   ||  |  | | |  +--rw upper-portinet:port-number
   ||  |  | | +--:(operator)
   ||  |  | |+--rw operator? operator
   ||  |  | |+--rw port  inet:port-number
   ||  |  | +--rw udp-all {match-on-udp}?
  

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

[Alex Campbell]

By the same reasoning surely UDP should not be available either, because it 
also doesn't provide security.

From: netmod  on behalf of Benoit Claise 

Sent: Wednesday, 17 January 2018 6:23 a.m.
To: Kent Watsen; netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

Hi,
>
>** Downref: Normative reference to an Historic RFC: RFC 6587
>
> Kent: hmmm, what's going on here?  This YANG module is providing an ability 
> to configure the "tcp" transport, even though the IESG made that ability 
> historic in 2012 (see IESG Note below).  Searching online, it looks like 
> Cisco supports this, but Juniper does not.  What about other vendors, is it 
> widely supported?  Was this discussed in the WG?  Answering my own question, 
> searching my local mailbox, I don't see this ever being discussed before, 
> other than Martin questioning if it was a good idea in Mar 2016 (no 
> response).  Please start a thread on the list to get WG opinion if it's okay 
> for the draft to proceed as is or not.  Here's the IESG Note from RFC 6587:
>
> IESG Note
>
> The IESG does not recommend implementing or deploying syslog over
> plain tcp, which is described in this document, because it lacks the
> ability to enable strong security [RFC3365].
>
> Implementation of the TLS transport [RFC5425] is recommended so that
> appropriate security features are available to operators who want to
> deploy secure syslog.  Similarly, those security features can be
> turned off for those who do not want them.
>
>
>
Well, I believe it's clear plain TCP should not be in the YANG module.

Regards, Benoit

___
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] evaluation of "when" under NMDA

[Alex Campbell]

Hi,

'when' does not affect schema nodes, only data nodes.
The schema nodes is essentially the YANG itself, without reference to any 
particular instance data.

Given an example YANG fragment:

list widgets {
key name;
leaf name {type string;}
leaf can-frob {type boolean;}
container frob-data {
when "../frob-data = 'true'";
leaf frob-count {type uint32; mandatory true;}
}
}

The schema could be written like this: (not in any real language)

widgets [list] [keys: name]
- name [name]
- can-frob [boolean]
- frob-data [container] [when ../frob-data = 'true']
- frob-count [uint32]

The when statement does not make schema nodes "valid" or "invalid". It only 
indicates the conditions under which the nodes will be present in the data tree.

A data tree for this schema might look like this: (in the same 
not-real-language)
widgets
- name: Widget1
- can-frob: false
widgets
- name: Widget2
- can-frob: true
- frob-data:
   - frob-count: 5

Widget1 doesn't have any frob-data because its can-frob is false, while Widget2 
does because its can-frob is true.
However that doesn't mean Widget1 and Widget2 have different schemas. They are 
both instances of the same schema written above.


From: netmod  on behalf of Ladislav Lhotka 

Sent: Tuesday, 5 December 2017 7:09 a.m.
To: Juergen Schoenwaelder
Cc: NETMOD WG
Subject: Re: [netmod] evaluation of "when" under NMDA

On Mon, 2017-12-04 at 18:22 +0100, Juergen Schoenwaelder wrote:
> On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote:
> > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > Hi,
> > > >
> > > > if we have
> > > >
> > > > augment "/target/node" {
> > > >   when "...";
> > > >   ...
> > > > }
> > > >
> > > > is the "when" expression supposed to be evaluated separately in each
> > >
> > > datastore,
> > > > and the augment applied only in those datastores where the result is
> > > > true?
> > >
> > > Yes.
> >
> > But then it cannot be guaranteed that the schema for  is a
> > superset
> > of the schema of configuration datastores - the when expression can evaluate
> > to
> > false in  but true in .
> >
>
> For me, its still the same schema - a when expression does not change
> my notion of 'schema'.

Well, according to draft-ietf-netmod-revised-datastores-07:

   o  datastore schema: The combined set of schema nodes for all modules
  supported by a particular datastore, taking into consideration any
  deviations and enabled features for that datastore.

And "when" determines whether a given schema node is valid or not. So if a
schema node is invalid in the schema of  but valid in the schema of
, then the former can hardly be a superset of the latter.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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] WG Last Call: draft-ietf-netmod-rfc7223bis-00

[Alex Campbell]

On page 37, "duplex" is mistyped as "duplexx".

Other than this minor error, I believe this draft is ready for publication.


From: netmod  on behalf of Kent Watsen 

Sent: Wednesday, 29 November 2017 8:29 a.m.
To: netmod@ietf.org
Cc: netmod-cha...@ietf.org
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7223bis-00.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

The working group last call ends on December 12.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt

Thank you,
Netmod Chairs


___
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] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Alex Campbell]

Hi,

I noticed the table in section 3 has been mangled - it has extra blank lines, 
entries in the wrong side of the table, and a missing pipe in the bottom right 
corner.

Apart from that this draft looks good to me.

From: netmod  on behalf of Kent Watsen 

Sent: Wednesday, 29 November 2017 8:29 a.m.
To: netmod@ietf.org
Cc: netmod-cha...@ietf.org
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7277bis-00.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

The working group last call ends on December 12.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt

Thank you,
Netmod Chairs

___
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] Notications in interface model

[Alex Campbell]

That is a good question.

In retrospect that seems like an obvious omission from the standard YANG.

I'm not aware of any other YANG that adds such a notification.




From: netmod  on behalf of Bogaert, Bart (Nokia - 
BE/Antwerp) 
Sent: Wednesday, 29 November 2017 12:29 a.m.
To: netmod@ietf.org
Subject: [netmod] Notications in interface model

Hello,

In the interfaces module we notice support of if-mib feature indicating whether 
the IF-MIB is supported or not.  Part of this feature is a flag to indicate 
whether an SNMP link-up/down trap has to be generated or not.  Looking at the 
YANG model itself we notice that it does not foresee any similar capability.  
We were wondering whether it has been discussed as part of the YANG model 
definition for interfaces to define a general status change notification in 
case an interface goes down or comes up and whether the generation of such a 
notification can be enabled or disabled?

Regards, Bart Bogaert


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

Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

[Alex Campbell]

Hi,
I've reviewed this latest draft and have some more comments.

1. I find the introduction to be unnecessarily wordy; it feels like it was 
written with a view of not missing any information out, rather than trying to 
keep it concise.
   For example, there is no need to elaborate on YANG data types here. It is 
also not here to sell YANG.

OLD:

   As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
   supported in the carrier networks, industrial networks, automotive
   networks, and many other applications. It can provide high
   precision time synchronization as fine as nano-seconds. The
   protocol depends on a Precision Time Protocol (PTP) engine to
   decide its own state automatically, and a PTP transportation layer
   to carry the PTP timing and various quality messages. The
   configuration parameters and state data sets of IEEE 1588-2008 are
   numerous.

   According to the concepts described in [RFC3444], IEEE 1588-2008
   itself provides an information model in its normative
   specifications for the data sets (in IEEE 1588-2008 clause 8). Some
   standardization organizations including the IETF have specified
   data models in MIBs (Management Information Bases) for IEEE 1588-
   2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
   typically focused on retrieval of state data using the Simple
   Network Management Protocol (SNMP), furthermore, configuration of
   PTP data sets is not considered in [RFC8173].

   Some service providers and applications require that the management
   of the IEEE 1588-2008 synchronization network be flexible and more
   Internet-based (typically overlaid on their transport networks).
   Software Defined Network (SDN) is another driving factor, which
   demands an improved configuration capability of synchronization
   networks.

   YANG [RFC6020] is a data modeling language used to model
   configuration and state data manipulated by network management
   protocols like the Network Configuration Protocol (NETCONF)
   [RFC6241]. A small set of built-in data types are defined in
   [RFC6020], and a collection of common data types are further
   defined in [RFC6991]. Advantages of YANG include Internet based
   configuration capability, validation, rollback and so on. All of
   these characteristics make it attractive to become another
   candidate modeling language for IEEE 1588-2008.

NEW:

   IEEE 1588-2008 is a time protocol that provides high precision time
   synchronization as fine as nano-seconds.

   IEEE 1588-2008 itself provides an information model in its normative
   specifications for the data sets (IEEE 1588-2008 clause 8).
   Standard information models (e.g. [RFC8173], [IEEE8021AS]) have been
   previously defined as MIBs focused on the retrieval of state data using
   SNMP [RFC1157].

   YANG [RFC6020] is a data modeling language used to model configuration
   and state data manipulated by network management protocols like NETCONF
   [RFC6241].

2. Can we refer to the system as simply PTP rather than IEEE 1588(-2008)?

3. There is insufficient spacing here to separate the terms from their 
definitions:
OLD

   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
   for PTP protocol decisions and for providing values for PTP message
   fields, see Section 8 of [IEEE1588].

   PTP instance A PTP implementation in the device (i.e., an OC or BC)
   represented by a specific PTP dataset.

NEW

   PTP dataset
 Structured attributes of clocks (an OC, BC or TC) used
 for PTP protocol decisions and for providing values for PTP message
 fields, see Section 8 of [IEEE1588].

   PTP instance
 A PTP implementation in the device (i.e., an OC or BC)
 represented by a specific PTP dataset.

4. There's a singular/plural mismatch here:

   module. Query and configuration of device wide or port specific
   configuration information and clock data set is described for this
   version.

and here:

   Query and configuration of clock information include:

5. The choice of uint16 as instance-number limits implementations to 65536 
distinct instances.
   While I have a hard time imagining a system with more than 65536 PTP 
instances, I would prefer to avoid imposing arbitrary limits.
   I would recommend changing instance-number to a string (and renaming it to 
instance-name or just name).

6. I still recommend removing -ds from the YANG element names that still 
include it. It doesn't appear to add any value.

7. What;s the relevance of injection attacks relevant to this YANG module?


Alex



From: netmod  on behalf of Jiangyuanlong 

Sent: Friday, 27 October 2017 3:21 p.m.
To: tic...@ietf.org
Cc: Xian Liu; Xujinchun; netmod@ietf.org
Subject: [netmod] WG Last Call resolutions incorporated in 
draft-ietf-tictoc-1588v2-yang-06

Dear all,

Based on all the comments we received during the WG Last Call process, we've 
updated the document to version 6.
We believe all the

Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-00.txt

[Alex Campbell]

Resending as I previously sent this to i-d-announces by mistake and it appears 
the whole message was rejected (i.e. it didn't get sent to netmod either)


Hi Xiaojian,

* The published module ietf-ip (RFC 7277) overlaps the data being provided in 
this module.
  Especially your /arp/arp-tables and /arp/arp-static-tables seem to correspond 
to /interfaces-state/interface/ipv4/neighbor and 
/interfaces/interface/ipv4/neighbor from ietf-ip.
  I think we should avoid duplication of data where possible; can you refactor 
this module to augment what is already there?

* Data relating to a specific interface should be inside /interfaces/interface 
(and -state) (ietf-interfaces, RFC 7223) where it is possible and relevant.
  I don't see any reason to have a completely separate list with a leafref as a 
key, when you could use 'augment' to have the data as part of the interface 
itself.

* ARP as a feature is not dependent on VRFs, but implementing this module 
requires the server to also implement ietf-network-instances.
  If the ARP-related data was under /interfaces(-state) then this draft 
wouldn't need to rely on ietf-network-instances.
  The network-instances draft already takes care of making sure each VRF has a 
separate list of interfaces.

Alex



From: netmod  on behalf of dingxiaojian (A) 

Sent: Thursday, 26 October 2017 10:27 p.m.
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: Re: [netmod] New Version Notification for 
draft-ding-netmod-arp-yang-model-00.txt

Hi all,

The ARP YANG module defined in this document has common properties that need to 
be configured.
It provides freedom for service providers to adapt this data model to different 
product implementations.

Please have a look and provide comments on the list.
Thanks,

Xiaojian


A new version of I-D, draft-ding-netmod-arp-yang-model-00.txt
has been successfully submitted by Xiaojian Ding and posted to the IETF 
repository.

Name:   draft-ding-netmod-arp-yang-model
Revision:   00
Title:  YANG Data Model for ARP
Document date:  2017-10-26
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-ding-netmod-arp-yang-model-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-ding-netmod-arp-yang-model/
Htmlized:   https://tools.ietf.org/html/draft-ding-netmod-arp-yang-model-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ding-netmod-arp-yang-model-00


Abstract:
   This document defines a YANG data model to describe Address
   Resolution Protocol (ARP) configurations.  It is intended this model
   be used by service providers who manipulate devices from different
   vendors in a standard way.




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.

The IETF Secretariat

___
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] New Version Notification for draft-ding-netmod-arp-yang-model-00.txt

[Alex Campbell]

Hi Xiaojian,

* The published module ietf-ip (RFC 7277) overlaps the data being provided in 
this module.
  Especially your /arp/arp-tables and /arp/arp-static-tables seem to correspond 
to /interfaces-state/interface/ipv4/neighbor and 
/interfaces/interface/ipv4/neighbor from ietf-ip.
  I think we should avoid duplication of data where possible; can you refactor 
this module to augment what is already there?

* Data relating to a specific interface should be inside /interfaces/interface 
(and -state) (ietf-interfaces, RFC 7223) where it is possible and relevant.
  I don't see any reason to have a completely separate list with a leafref as a 
key, when you could use 'augment' to have the data as part of the interface 
itself.

* ARP as a feature is not dependent on VRFs, but implementing this module 
requires the server to also implement ietf-network-instances.
  If the ARP-related data was under /interfaces(-state) then this draft 
wouldn't need to rely on ietf-network-instances.
  The network-instances draft already takes care of making sure each VRF has a 
separate list of interfaces.

Alex

From: netmod  on behalf of dingxiaojian (A) 

Sent: Thursday, 26 October 2017 10:27 p.m.
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: Re: [netmod] New Version Notification for 
draft-ding-netmod-arp-yang-model-00.txt

Hi all,

The ARP YANG module defined in this document has common properties that need to 
be configured.
It provides freedom for service providers to adapt this data model to different 
product implementations.

Please have a look and provide comments on the list.
Thanks,

Xiaojian


A new version of I-D, draft-ding-netmod-arp-yang-model-00.txt
has been successfully submitted by Xiaojian Ding and posted to the IETF 
repository.

Name:   draft-ding-netmod-arp-yang-model
Revision:   00
Title:  YANG Data Model for ARP
Document date:  2017-10-26
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-ding-netmod-arp-yang-model-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-ding-netmod-arp-yang-model/
Htmlized:   https://tools.ietf.org/html/draft-ding-netmod-arp-yang-model-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ding-netmod-arp-yang-model-00


Abstract:
   This document defines a YANG data model to describe Address
   Resolution Protocol (ARP) configurations.  It is intended this model
   be used by service providers who manipulate devices from different
   vendors in a standard way.




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.

The IETF Secretariat

___
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] WGLC for draft-ietf-tictoc-1588v2-yang

[Alex Campbell]

Hi,
I've reviewed the draft and found the following issues.

* YANG enumeration values are conventionally lowercase, but the 
delay-mechanism-enumeration and port-state-enumeration types in the draft have 
uppercase values.
* Similarly, hyphens should be used rather than underscores (pre-master instead 
of PRE_MASTER)
* number-ports doesn't read naturally in English; I suggest renaming it to 
number-of-ports.
* The description of port-ds-list contains a typo - "memer" instead of "member".
* There's no need to have groupings that are only used once (such as 
parent-ds-entry, current-ds-entry, default-ds-entry, 
transparent-clock-default-ds-entry, port-ds-entry, 
transparent-clock-default-ds-entry, and so on) unless this is for 
futureproofing or some other reason I'm not aware of.
* Is it necessary to include -ds in the name of every leaf, container and 
grouping?

Note I'm not familiar with IEEE 1588, apart from a brief look through it just 
now.

Alex



From: netmod  on behalf of Jiangyuanlong 

Sent: Friday, 15 September 2017 1:42 p.m.
To: netmod@ietf.org
Cc: tic...@ietf.org
Subject: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang

Hi netmoders,

This draft does not tackle the general YANG problem, but provide a generic time 
synchronization module of 1588.
Some of you may have interests in time synchronization, some definitely not. 
But as experts in YANG, could you please have a review of this YANG module and 
give an expert opinion?

Thanks,
Yuanlong

-Original Message-
From: TICTOC [mailto:tictoc-boun...@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, September 14, 2017 3:16 AM
To: tic...@ietf.org
Cc: n...@ietf.org
Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

Folks,

This message begins a 2 week working group last call (WGLC) for the following 
document:

YANG Data Model for IEEE 1588v2
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

Please review the referenced document and send any comments to the mailing list 
including your assessment of whether this document is mature enough to proceed 
to the IESG. Please note that these messages of support for progression to the 
mailing list are important and will be used to determine WG consensus to 
proceed.

Please send all comments in by Thursday 28 September 2017.

Thank you!
Karen
___
TICTOC mailing list
tic...@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

___
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] Potential additions to rfc6087bis: RegEx guidelines

[Alex Campbell]

Hi,


I'd be very wary of adding guidelines that restrict the regex syntax.


A tool that supports YANG must implement the full regex language anyway (or 
ignore regexes altogether if they are not relevant to the tool's function). 
However, these guidelines will inevitably encourage some tool authors to take 
shortcuts.


I'm sure there are already tools that take shortcuts - but if the shortcuts 
cause problems, right now it's squarely the tool's fault, rather than the model 
being processed.

If there are official guidelines saying not to use such-and-such regex feature, 
then the tool author can point to the guideline and say "See? You aren't 
supposed to be using that".


We may end up with a compatibility nightmare on our hands where certain modules 
are only compatible with certain tools, even more-so than is the case now.


The only way I'd ever approve of this is if it was a MUST requirement in a new 
version of YANG.




From: netmod  on behalf of Robert Wilton 

Sent: Thursday, 31 August 2017 4:44 a.m.
To: Andy Bierman; Juergen Schoenwaelder; Xufeng Liu; netmod@ietf.org
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines


Hi,

On 30/08/2017 15:52, Andy Bierman wrote:


On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
>
>
> On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> > > Hi Andy,
> > >
> > > What I am suggesting makes it easier for readers, because I am a proponent
> > > of simpler regular expressions that are easy to read and understand.
> > >
> > > For example, I wonder how many YANG model readers would immediately
> > > comprehend what this pattern statement means:
> > >
> > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> > >
> > > Does allowing such patterns really make it easier for model readers?
> > This is always difficult to judge but to be fair you have to show how
> > you express _the same_ (and not a subset) with some other kind of
> > regular expressions. (My understanding is that \p{Sc} is a currency
> > symbol.)
> Yes, the expression would cover a currency amount, along with associated
> symbol (e.g. "$200.00").
>
> If I was writing a module, I would probably use the following pattern
> statement instead, which I think a lot more people would likely be able to
> comprehend:
>
> pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, currency 
> codes.  e.g. ("USD 200.00")

But that is not the same. Apples versus oranges. (I expect people to
tell me that (i) currency is irrelevant and (ii) that three ASCII
letter currency acronyms are better than currency symbols anyway but
this is a separate discussion I am not interested in.)

> >
> > > The proposes guidelines obviously make it easier (or at least no harder) 
> > > for
> > > tool makers.
> > >
> > > I agree that there is an minor impact to model writers, but really only in
> > > the sense that the guidelines would be telling them not to use the 
> > > esoteric
> > > options of the XML regex syntax that they probably don't know about 
> > > anyway.
> > What is 'esoteric' largely depends on your language environment. What
> > you are saying by 'do not use \p{}' is essentially 'do not use any
> > unicode long live ASCII'.
> No, that is not my intention, i.e. I'm not suggesting banning all use of
> \p{}, but instead limiting it to the character classes that seem like they
> may plausibly be used in standardized YANG modules.

This is entirely subjective. And if you still allow some \p{}, what is
the point of the exercise?

> I'm not trying to change what 6020/7950 defines the pattern statement as,
> just give what I perceive as some pragmatic guidance as to what parts of XML
> RE it makes sense to use in standardized YANG modules, making it easier for
> readers and implementations.
>
> I think that it is fine for companies, vendors, etc to use the full breadth
> of XML RE if they wish.

Implementations have to be prepared to handle XSD pattern if they
claim compliance to YANG 1.0 and 1.1. So all this only helps
non-compliant implementations. This may indeed be a goal - but then we
should spell this out as such - this helps non-compliant
implementations (and they may still fail on the first \p{} that
you still allow).

If implementations do not implement the YANG pattern statement but
something else, then then they should ignore patterns they can't
understand and treat the pattern as if it would have been in a
description clause - i.e., leave it to humans to write the code that
implements the pattern correctly. Note that YANG does not say anything
how stuff is implemented.


This does not work.
There are 3 outcomes from the regex compiler

1) proper syntax was used and accepted; pattern matches correctly
2) improper syntax was used and accepted; pattern matches incorrectly
3) impro

Re: [netmod] Query about augmenting module from submodule in YANG 1.0

[Alex Campbell]

Hi,

I'm not Rob, but my understanding is that if a module author wanted to migrate 
to YANG 2.0, they could merge their submodules back into the main module - 
which is not a difficult procedure and does not break compatibility with 
clients.

Alex

From: netmod  on behalf of Ivory, William 

Sent: Tuesday, 22 August 2017 1:44 a.m.
To: 'Robert Wilton'; 'netmod@ietf.org'
Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0

Hi Rob,

That would make it very hard to update existing 1.x YANG models to use new 
features in YANG 2.x if they used submodules.  Maybe that's something that no 
one would ever consider doing anyway, or maybe YANG 1.1 already has similar 
differences to 1.0?  I had (perhaps naively) assumed that you could migrate a 
namespace / model from YANG 1.0 to 2.0?

Regards,

William

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: 21 August 2017 11:24
To: netmod@ietf.org
Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0



On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>> I remember that in early stages of YANG there was some irrational
>> fear of introducing too many namespaces, and submodules may be a
>> consequence of it. As you write, submodules provide no benefits
>> whatsoever in terms of modularity, but the overhead in terms of
>> metadata, IANA registration etc. is pretty much the same as for
>> modules.
> In case YANG 2.0 is ever done, I suggest someone files a proposal to
> remove submodules if the cost/benefit ratio is at odds. There is
> nothing wrong with removing stuff that has been found problematic.
I agree.

I've added 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=

Rob

>
> The motivation for submodules was that organizations maintaining large
> modules with multiple people can do so without having to mess around
> with tools like m4 scripts to produce a single module from 'snippets'
> and to avoid integration surprises. But perhaps using m4 scripts and
> decent version control systems (that can integrate and compile on
> checkin) is indeed cheaper than having submodules part of the YANG
> language itself.
>
> /js
>

___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=

___
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] accessible tree for rpcs?

[Alex Campbell]

Why would it not make sense? Is your question about the datastores proposal?

Usually an action will refer to some object that is defined as configuration 
and/or state, and may depend on the particular properties of that object.
Here is a YANG fragment showing one possible application:

list ospf-instance {
config true;
leaf id {type string;}
leaf supports-graceful-restart {type boolean;}
}

rpc ospf-graceful-restart {
input {
leaf instance-id {type leafref {path "/ospf-instance/id";}}
must 
"/ospf-instance[id=current()/instance-id]/supports-graceful-restart = 'true'" {
error-message "Instance does not support graceful restart";
}
}
}

As another application, a "mute transmitter" command might only apply to 
digital radio interfaces.

Alex


From: netmod  on behalf of Kent Watsen 

Sent: Wednesday, 2 August 2017 3:37 a.m.
To: netmod@ietf.org
Subject: [netmod] accessible tree for rpcs?

RFC 7950, S6.4.1. (XPath Context) says:

   o  If the XPath expression is defined in a substatement to an "input"
  statement in an "rpc" or "action" statement, the accessible tree
  is the RPC or action operation instance, all state data in the
  server, and the running configuration datastore.  The root node
  has top-level data nodes in all modules as children.
  Additionally, for an RPC, the root node also has the node
  representing the RPC operation being defined as a child.  The node
  representing the operation being defined has the operation's input
  parameters as children.

   o  If the XPath expression is defined in a substatement to an
  "output" statement in an "rpc" or "action" statement, the
  accessible tree is the RPC or action operation instance, all state
  data in the server, and the running configuration datastore.  The
  root node has top-level data nodes in all modules as children.
  Additionally, for an RPC, the root node also has the node
  representing the RPC operation being defined as a child.  The node
  representing the operation being defined has the operation's
  output parameters as children.


Does it make sense for input/output to access "all state data in the
server, and the running configuration datastore"?  How would this be
used?


Kent  // contributor






___
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] draft-wilton-netmod-interface-properties-00

[Alex Campbell]

Hi,

I would very much like to see this happen.

However I recommend at least splitting up "ethernet-like" into 
"ethernet-mac-like" and "ethernet-phy-like". At Aviat we have microwave radio 
interfaces that behave like Ethernet at the MAC level but have totally 
different PHYs. The distinction is also useful for virtual links, such as link 
aggregations and tunnels.


From: netmod  on behalf of Ladislav Lhotka 

Sent: Wednesday, 26 July 2017 9:27 p.m.
To: Robert Wilton; netmod@ietf.org
Subject: Re: [netmod] draft-wilton-netmod-interface-properties-00

Hi Rob,

I think this is a very useful work and we will probably implement it
soon. A few comments:

- I support the proposed redesign of "iana-if-type" but I believe this
  module should in fact be declared historic. For one, the name of the
  most frequently used type, "ethernetCsmacd", is not only notoriously
  hard to remember but it is also a misnomer: these days, almost no
  Ethernet network uses CSMA/CD any more. Instead, "csma-cd" can be
  another identity that could be added to the mix of bases where
  necessary.

- Interface type identities should be defined in a distributed way and
  not in a single module as in "iana-if-type". A module defining
  configuration and state data for a particular technology should also
  define the corresponding identity or identities. This way, the choice
  of interface types will always be limited to those supported by a
  specific server.

- In Appendix B I don't understand the comment in the definition of
  container "encapsulation": what could be the abstract type and how
  would it aid extensibility?

Thanks, Lada

Robert Wilton  writes:

> Hi,
>
> In the NETMOD session on Wednesday I will spend 5 minutes speaking on
> draft-wilton-netmod-interface-properties-00, that has been created due
> to discussions with various folks to handle interface type specific
> configuration.
>
> The draft isn't particularly long, 21 pages, two thirds of that is just
> examples, and it is presenting a simple idea.
>
> In particular, it is aiming at solving the problem of when statements
> like this:
>
>   augment "/if:interfaces/if:interface" {
> when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
>   derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
>   derived-from-or-self(if:type, 'ianaift:l2vlan') or
>   derived-from-or-self(if:type, 'ianaift:ifPwType')" {
>   description "Applies to all Ethernet-like interfaces";
> }
>
> and instead proposes this:
>
>  augment "/if:interfaces/if:interface" {
>when "derived-from(if:type, 'ianaifp:ethernet-like')" {
>  description
>"Applies to all interfaces that derive from the Ethernet-like
> interface property.";
>}
>
> The core idea being that new identities are defined to represent
> interface properties (like ethernet-like) and the existing interface
> types iana-if-types.yang are updated to also derive from the new
> interface properties.
>
> This simplifies the YANG, should make interface based configuration more
> future proof, since new interface types can also derive from the
> appropriate interface properties.  Of course additional interface
> properties could also be defined.
>
> I'm seeking input from the WG as to whether they like this approach, AND
> also whether the WG drafts: draft-ietf-netmod-intf-ext-yang-05 and
> draft-ietf-netmod-sub-intf-vlan-model-02 should be updated to make use
> of this approach (possibly in a future bis revision to avoid delaying
> publishing the models).
>
> Thanks,
> Rob
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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] ACL draft defines ether-type as a string

[Alex Campbell]

Doesn't this mean that if a new protocol is defined, then it won't be usable in 
ACLs until the server's data model is upgraded? (And with many devices, that is 
quite likely never)



From: netmod  on behalf of Mahesh Jethanandani 

Sent: Tuesday, 18 July 2017 6:21 p.m.
To: NetMod WG
Subject: [netmod] ACL draft defines ether-type as a string

The issue of ether-type defined as a string was discussed with participants 
from IEEE in IETF. It was generally agreed that since ether-types are well 
known values, and centrally managed, that they be defined as enumerations. 
There was some clarification sought by IEEE on which values need to be 
published. It was suggested that ether-types that are either private or do not 
have a protocol identified would be named as ether-type-0x where 0x 
represents the value assigned. All the remaining ether-types will be defined as 
enums with the well known names.

As far as the impact of that on the ACL draft is concerned, it will be to 
remove all local definitions for ether-type from the draft, such as the one 
below and instead use the definition from IEEE, whenever that is done. It does 
however put a dependency on the IEEE model.


leaf ether-type {
  type string {
pattern '[0-9a-fA-F]{4}';
  }
  description
"The Ethernet Type (or Length) value represented
 in the canonical order defined by IEEE 802.
 The canonical representation uses lowercase
 characters.

 Note: This is not the most ideal way to define
 ether-types. Ether-types are well known types
 and are registered with RAC in IEEE. So they
 should well defined types with values. For now
 this model is defining it as a string.


 There is a note out to IEEE that needs to be
 turned into a liaison statement asking them to
 define all ether-types for the industry to use.";
  reference
"IEEE 802-2014 Clause 9.2";
}
reference
  "IEEE 802: IEEE Standard for Local and Metropolitan
   Area Networks: Overview and Architecture.";
  }

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Alex Campbell]

I am considering to implement the data model in this draft. (dependent on 
business priorities of course)
I have reviewed this draft and found the following issues.

* I see pattern-match is specified to use POSIX 1003.2 regular expressions. 
This is presumably for compatibility with existing implementations; however it 
is inconsistent with most of YANG (which is specified to use XPath regular 
expressions) - unless these are the same.
* pattern-match is inside the facility-filter container; common sense says this 
is wrong as pattern-match has nothing to do with facilities.
* The advanced-compare container groups together two nodes that share a common 
"when" and "if-feature" statement, but don't seem to have any semantic relation 
to each other. Are there general guidelines on when to use a container?
* The advanced-compare container has a description starting with "This leaf 
..." even though it is not a leaf.
* The examples are missing  nodes.
* Perhaps there should be more consistent terminology for receivers of syslog 
messages; both "collectors" and "actions" are used in the draft. RFC 5424 uses 
"collector" for the ultimate recipient of a log message - which might not be 
applicable, because the sending system has no idea whether the receiving system 
is a collector or a relay.





From: netmod  on behalf of Kent Watsen 

Sent: Saturday, 8 July 2017 6:34 a.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

This is a notice to start a three week NETMOD WG last call for the
document:

A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-15

Note: Three weeks is more than needed, especially given this
  draft has been through Last Call before, but we understand
  folks are busy these days.

Please indicate your support or concerns by Friday, July 28, 2017.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

As well as:
  * I have implemented the data model in this draft.
  * I am implementing the data model in this draft.
  * I am considering to implement the data model in this draft.
  * I am not considering to implement the data model in this draft.

Thank you,
NETMOD WG Chairs




___
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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Alex Campbell]

There are many different layers and all, or none of them could be called 
configuration depending on your perspective.
Consider the current set of routes on a router. I think we can all agree that 
from the point of view of the Linux kernel, or a hardware routing chip, this is 
configuration data.
But from the point of view of an OSPF process it is operational data. OSPF will 
reconfigure Linux every time the routes change.
Even *static* routes may be considered operational data at an even higher level 
(such as a network monitoring system).


From: netmod  on behalf of Joel M. Halpern 

Sent: Wednesday, 21 June 2017 6:19 a.m.
To: t.petch; Robert Wilton; netmod@ietf.org
Subject: Re: [netmod] Defining configuraiton: was I-D Action: 
draft-ietf-netmod-rfc6087bis-13.txt

I was going to just watch this, but I can't.

To call protocol negotiated values "configuration" is to create a usage
which will confuse MANY people.  Even worse, configuring protocol
learned values is liable to break things.  To use one example, many
protocols negotiate timers.  The value that a given systems starts with
is the configured value.  The value that it learns from the protocol
exchange is the operational value.  In fact, you better not try to
configure that value or you are liable to break the protocol.

Yours,
Joel


On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote:
> On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote:
>>
>> Robert
>>
>> The definition of 'configuration' in netmod-revised-datastores-02 is
>> very different from what has gone before in NETCONF and NETMOD.
>>
>> You start with
>> 'Data that determines how a device behaves.'
>> which is how I would have defined configuration before the days of
>> NETCONF and which I imagine is how many who have not been exposed to
>> NETCONF would still do.  NETCONF narrowed the definition a lot; 'Data
>> that determines how a device behaves' opens it up again.
>>
>> You add the qualification 'using "config true" nodes' which doesn't
>> really mean anything in this context, unless you already know some YANG
>> models, and know what is modelled in this way and what is not and so can
>> work it out, reverse engineering.
>>
>> Coming to netmod-revised-datastores-02  with an innocent eye, knowing
>> that the ground has moved, that some of my assumptions of the past 10
>> years are no longer valid, then these definitions convey to me that
>> configuration acquired from the system or from routing protocols, to
>> take two common examples, will now always be modelled 'config true',
>> that is the first sentence is the definition and the second - 'config
>> true' - is the consequence thereof.
>>
>> Of course, if you come to the I-D knowing otherwise, then you may find a
>> different interpretation but I do not think that that is the obvious
>> interpretation.
>>
>
> Is your proposal to take out "This data is modeled in YANG using
> "config true" nodes."?
>
> Note that the NMDA document further defines
>
> o  conventional configuration: Configuration that is stored in any of
>the conventional configuration datastores.
>
> o  dynamic configuration: Configuration obtained via a dynamic
>datastore.
>
> o  learned configuration: Configuration that has been learned via
>protocol interactions with other systems that is not conventional
>or dynamic configuration.
>
> o  system configuration: Configuration that is supplied by the device
>itself.
>
> o  default configuration: Configuration that is not explicitly
>provided but for which a value defined in the data model is used.
>
> There are corresponding origin attribute definitions. (With the minore
> caveat that the origin value for conventional configuration is
> intended since this is the datastore conventional configuration
> finally originates from.)
>
> /js
>

___
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] Question on intefaces-state model

[Alex Campbell]

Presumably a device is free to not implement an optional config=false node if 
that node would never be returned in a response anyway - as this will make no 
externally visible difference.

However, if the model states or implies that the node is present under certain 
conditions (for example, the node is always present for Ethernet ports), and 
the device can meet those conditions (i.e. it has an Ethernet port), then the 
device must implement the node or it does not conform to the model.



Alex


From: netmod  on behalf of Andy Bierman 

Sent: Wednesday, 14 June 2017 7:30 a.m.
To: Ladislav Lhotka
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model


On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka 
mailto:lho...@nic.cz>> wrote:
Andy Bierman mailto:a...@yumaworks.com>> writes:

> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>
>  wrote:
>
>> On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
>> BE/Antwerp) wrote:
>> >
>> > We have a question regarding the statistics container as defined in the
>> > interfaces-state model.  This container defines one mandatory leaf
>> > (discontinuity-time) while all other leafs are optional.  What is the
>> > rationale behind this leaf being mandatory and not an optional field?
>> >
>> > It does not make a lot of sense to return a discontinuity-time value and
>> no
>> > counters if none of the counters are relevant for a specific interface.
>> >
>> > Another alternative could be to add, via a deviation, a when clause to
>> the
>> > container indicating for which ifType(s) the container is (or is not)
>> > present. But that would lead to not supporting the IETF interfaces model
>> to
>> > the full extent.
>> >
>>
>> The discontinuity-time is relevant for _any_ counter associated with
>> an interface, regardless whether the counter is defined in the
>> interfaces model or elsewhere. I have a hard time to imagine an
>> interface that has zero counters.
>>
>>
> The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
> means
> an  must contain an instance of the mandatory leaf.

I don't think it is that confusing. RFC 7950 defines what a valid data
tree means and "mandatory" are among the constraints.

I agree though that in terms of a management protocol it means different
things for config true and false data, but this is true also for default
values and maybe other YANG concepts as well.

>
> Mandatory=false does not mean optional-to-implement although it sure
> looks that way for config=false nodes.  Only if-feature can make a node
> optional to implement.

I don't think this interpretation is supported by any text in the YANG
spec. State data nodes that are optional needn't be implemented.


RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
It defines basic behavior, optional (via features), and deviations as the only 
mechanisms affecting conformance.


Lada

>


Andy

>
>
>  /js
>
>
> Andy
>
> --
>> 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
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

[netmod] Question about ietf-routing

[Alex Campbell]

Hi,

I noticed that the ietf-routing YANG (published in RFC 8022) allows for 
multiple instances of each control plane protocol, as well as multiple RIBs per 
address family.
However I don't see any way to associate one with the other. Without additional 
configuration, protocols will only place their routes in default RIBs.
Is it intended that this will be left to vendor-specific modules and/or future 
standards?

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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt

[Alex Campbell]

Hi,

In the description of /hardware-state/component, which describes the procedure 
for matching newly added hardware components with pre-configured entries in 
/hardware/component:

What happens if hardware-config is supported, and there is no entry with 
matching values for the nodes 'class', 'parent', and 'parent-rel-pos'? (i.e. 
step 1's condition is not true)
Why is mfg-name treated specially - and not, for example, serial-num?
Why is it recommended for implementations to warn about a mfg-name mismatch, 
but not a class mismatch?




From: netmod  on behalf of Martin Bjorklund 

Sent: Monday, 13 March 2017 8:46 p.m.
To: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt

Hi,

This version addresses the comments from Bart and Juergen.

I think that this document is now ready for WGLC.


/martin


internet-dra...@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 of the IETF.
>
> Title   : A YANG Data Model for Hardware Management
> Authors : Andy Bierman
>   Martin Bjorklund
>   Jie Dong
>   Dan Romascanu
>   Filename: draft-ietf-netmod-entity-03.txt
>   Pages   : 40
>   Date: 2017-03-13
>
> Abstract:
>This document defines a YANG data model for the management of
>hardware on a single server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-entity-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03
>
>
> 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

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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

[Alex Campbell]

I can confirm that this new draft addresses my concerns and doesn't add any new 
ones.



From: Kent Watsen 
Sent: Wednesday, 22 February 2017 10:28 a.m.
To: Clyde Wildes (cwildes); netmod@ietf.org
Cc: Andy Bierman; Alex Campbell
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Thanks for the update you Clyde!

Alex/Andy, since this update was made per comments you made during Last Call, 
can you please confirm that it does indeed address your concerns, and doesn't 
add any new ones?

Thanks,
Kent

On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" 
mailto:netmod-boun...@ietf.org> on behalf of 
cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:

Hi,

I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns 
that Alex and Andy raised in their review of draft 11.

Changes from draft 11 to draft 12 can be seen at this link:
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff

Please review and comment.

Thanks,

Clyde

From: "Clyde Wildes (cwildes)" 
Date: Wednesday, January 11, 2017 at 2:54 PM
To: Andy Bierman 
Cc: Alex Campbell , "netmod@ietf.org" 

Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Any

My comments inline as [clyde2]…

From: Andy Bierman 
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)" 
Cc: Alex Campbell , "netmod@ietf.org" 

Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11



On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) 
mailto:cwil...@cisco.com>> wrote:
Hi Andy,

Thanks for taking the time to review the model.

My comments are inline as [clyde]…

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell 
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi,

I am also considering an implementation.
I share the same concerns that Alex has brought up.

Some detailed comments:

1) /syslog/actions: seems like everything is in this container.
 Why is it needed?  Seems like it could be removed as it serves no purpose

[clyde] Although this model is currently designated as config only, we could 
add operational data and rpc leaves in the future. The actions container is to 
future-proof the model.

2) 8 features: the granularity seems wrong.  The main container for each section
 should have its own if-feature
  /console
  /buffer
  /file
  /remote

[clyde] We have gone back and forth on this…some have complained that there are 
too many features. I will be happy to add a feature for each action. Note that 
we studied the implementation of each action by six vendors including Linux and 
opted to not add features for actions implemented by at least 3 vendors. 
Vendors not implementing an action could create a deviation.


I prefer 1 mandatory-to-implement and a minimal number of additional options.

  /console
  /file
  /remote

These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.

[clyde2] I will remove the buffer and session actions in the next draft and 
will make the remaining three features.


3) What is the 'buffer' container for?
  How is the internal memory accessed by the client?

[clyde] buffer is implemented by vendors typically for routers capable of 
generating many syslog messages in event-storm bursts. Logging to memory (aka 
buffer) allows the preservation of syslog messages which might otherwise be 
lost.



IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring.  Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.

There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.

[clyde2] The buffer action will be removed.
A “show log” command is used to access the buffers. As this model is current 
designed as a configuration only model, there is no operational leaves for show 
log, or rpc leaves for clear log.

4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the 
facility-list

[clyde] This was changed as a result of Alex’s feedback – please see my 
response to him. The model will be changed to the following:


container selector {

  description

"This container describes the log selector parameters

 for syslog.";

  list facility-list {

  

Re: [netmod] Hi all, one issue about YANG deviate's Substatements

[Alex Campbell]

Hi,


I believe you misunderstood the intention.

A "when" statement inside a deviation would simply add/remove/update a "when" 
statement in the target module. It would not make the deviation conditional.


I asked this some time ago, and for some reason I was told that it would be 
overly complex to implement, and to use a "must" statement instead. But I 
disagree with this resolution.


Alex



From: netmod  on behalf of Andy Bierman 

Sent: Wednesday, 22 February 2017 8:23 a.m.
To: Zhengguangying (Walker)
Cc: Qudan (Beijing-NOS); netmod@ietf.org; Yangang
Subject: Re: [netmod] Hi all, one issue about YANG deviate's Substatements



On Tue, Feb 21, 2017 at 12:32 AM, Zhengguangying (Walker) 
mailto:zhengguangy...@huawei.com>> wrote:
Hi all,

  When we define YANG models, there has one issue about "deviate's 
Substatements"

  In section 7.20.3.2.  The "deviate" Statement given the Substatements 
supported, but "when" not there.
config   | 7.21.1   | 0..1|
   | default  | 7.6.4, 7.7.4 | 0..n|
   | mandatory| 7.6.5| 0..1|
   | max-elements | 7.7.6| 0..1|
   | min-elements | 7.7.5| 0..1|
   | must | 7.5.3| 0..n|
   | type | 7.4  | 0..1|
   | unique   | 7.8.3| 0..n|
   | units| 7.3.3| 0..1|
   +--+--+-+
Now, we have the scenario to add "when" constrains when deviate the existed 
YANG module, how I can do it?


You cannot add when-stmts to deviations.
It is not supported.  Deviations cannot be conditional.

May be it need extend the Substatements of "devite" to add "when", what's yours 
opinion, please help to share, thanks.

Thanks & regards

Walker (Guangying zheng)




Andy


___
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] Yang 1.1 change: Allow type "empty" in a key.

[Alex Campbell]

Hi,


It means exactly what the summary says. In YANG 1.0 (RFC 6020) we have:

   A leaf that is part of the key can be of any built-in or derived
   type, except it MUST NOT be the built-in type "empty".

and in YANG 1.1 (RFC 7950) we have:

   A leaf that is part of the key can be of any built-in or
   derived type.

In YANG 1.1, leaves of type "empty" are not disallowed from being keys.

Note that since leaves of type "empty" only convey information through their 
presence or absence, and since
key leaves must always be present, key leaves of type "empty" convey no useful 
information.



Alex




From: netmod  on behalf of Martin Ciglan -X (mciglan - 
PANTHEON TECHNOLOGIES at Cisco) 
Sent: Wednesday, 15 February 2017 2:48 a.m.
To: netmod@ietf.org
Cc: Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco)
Subject: [netmod] Yang 1.1 change: Allow type "empty" in a key.


Hi all


Yang 1.1 change:  Allow type "empty" in a key.


What is the meaning of this change? We're interested from implementation point 
of view.


  Thanks


   Martin

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

Re: [netmod] top-level mandatory nodes

[Alex Campbell]

Here's a straightforward, hypothetical use case where a mandatory top-level 
non-config leaf makes sense (in my opinion anyway):

module example-uptime {
prefix uptime;
namespace urn:X-example:example-uptime;

import ietf-yang-types {
prefix yang;
}

leaf uptime {
type yang:timeticks;
config false;
mandatory true;

description "The amount of time since the server was last powered 
on or restarted.";
}
}

- Alex


From: Phil Shafer 
Sent: Thursday, 19 January 2017 12:51 p.m.
To: Alex Campbell
Cc: Ladislav Lhotka; NETMOD WG
Subject: Re: [netmod] top-level mandatory nodes

I was really looking for a use case.  What's is a specific scenario
where one would want a device to always report data even when there
is no interesting data to report (since interesting data would mean
the device would want to report it)?

I've seen this misused where the modeler wants the device to say
"I've got no TLA data", where the model should be happy that being
implicit in the lack of data.

Thanks,
 Phil



Alex Campbell writes:
>The purpose of a mandatory config=false node is to say that the data is 
>_always_ needed.
>
>In the case where the node is also top-level, if your server fails to provide 
>that data,
> then your server is not compliant with the YANG.
>
>If the data is sometimes not needed, then the module author should not have 
>marked it as
> mandatory.
>
>Alex
>
>
>From: netmod  on behalf of Phil Shafer 
>
>Sent: Thursday, 19 January 2017 10:35 a.m.
>To: Ladislav Lhotka
>Cc: NETMOD WG
>Subject: Re: [netmod] top-level mandatory nodes
>
>Ladislav Lhotka writes:
>>>> 6087bis says in sec. 5.10:
>>>>  Top-level database data definitions MUST NOT be mandatory.
>>Right - I think the following should do:
>>OLD
>>  Top-level database data definitions MUST NOT be mandatory.
>>NEW
>>  Top-level data nodes that represent configuration MUST NOT be mandatory.
>
>[old news, but...]
>
>I guess I'm missing the use case for mandatory top-level config=false
>data models.  Can you please describe one?  I imagine that just because
>my device implements a non-config data model, I should not be forced
>to generate data for it when/if that data is not needed.  What's the
>scenario where I need to be forced to make this data?
>
>Thanks,
> Phil
>
>___
>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] top-level mandatory nodes

[Alex Campbell]

The purpose of a mandatory config=false node is to say that the data is 
_always_ needed.

In the case where the node is also top-level, if your server fails to provide 
that data, then your server is not compliant with the YANG.

If the data is sometimes not needed, then the module author should not have 
marked it as mandatory.

Alex


From: netmod  on behalf of Phil Shafer 

Sent: Thursday, 19 January 2017 10:35 a.m.
To: Ladislav Lhotka
Cc: NETMOD WG
Subject: Re: [netmod] top-level mandatory nodes

Ladislav Lhotka writes:
>>> 6087bis says in sec. 5.10:
>>>  Top-level database data definitions MUST NOT be mandatory.
>Right - I think the following should do:
>OLD
>  Top-level database data definitions MUST NOT be mandatory.
>NEW
>  Top-level data nodes that represent configuration MUST NOT be mandatory.

[old news, but...]

I guess I'm missing the use case for mandatory top-level config=false
data models.  Can you please describe one?  I imagine that just because
my device implements a non-config data model, I should not be forced
to generate data for it when/if that data is not needed.  What's the
scenario where I need to be forced to make this data?

Thanks,
 Phil

___
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] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[Alex Campbell]

IMO it should be treated like any other protocol error.
Which means that an ideal client will report an error - but in practice they'll 
end up ignoring the constraint violation because it's easier to not do 
validation.

This problem isn't specific to YANG - what happens if I make a request to an 
HTTP server ("GET / HTTP/1.1") and the server sends back nonsense 
("FOOBAR/-1.3i xyz Didn't feel like it")?
A good client will report that there was an error parsing the response; a bad 
client might call atoi on the second field (recording the status code as 0) and 
ignore the other fields.
Is there anything we can do about that? I don't think there is.

Alex


From: netmod  on behalf of Juergen Schoenwaelder 

Sent: Friday, 13 January 2017 7:44 a.m.
To: Andy Bierman
Cc: Netconf; netmod@ietf.org
Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised 
DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote:
> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote:
> > >
> > > YANG statements:
> > >- It is not possible to define these statements so they are different
> > > for config and oper
> > >   - must
> > >   - when
> > >   - unique
> > >   - key
> > >   - min-elements
> > >   - max-elements
> > >   - leafref (path)
> > >   - if-feature
> > >   - deviation
> > >   - type (or any sub-statements of type-stmt)
> > >   - status
> > >   - description
> > >   - reference
> >
> > Considering statements that constraint 'values', it is not entirely
> > clear to me what they mean for state nodes. If a server has
> > operational state that violates a must or range or ... constraint in
> > the YANG model, what is the server expected to do?
> >
>
> The client uses the YANG validation to check on what the server is sending.
> The server is buggy if it is sending data that violates YANG constraints.
> If any of these statements need to be different for config and oper
> then the old style YANG has to be used instead.
>

OK. So the client does the validation. What does the client do if the
operational state it got is not valid according to the YANG constraints?

/js

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

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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

[Alex Campbell]

Hi,

I approve of all of your proposed changes.

However, I'm still not sure that "[implementing] the minimum set of 
functionality that is contained in at least three vendor implementations" is a 
sensible policy.
The fact that three vendors produce devices that support a feature doesn't 
necessarily mean that every device that would implement this model supports the 
feature - especially for a widely-used, generic model such as syslog.

In my opinion the syslog model should be designed to accommodate all sorts of 
devices, not just rack-mount switches and routers.
For example, many IP phones don't have a console or an accessible filesystem. 
(Just an example; I'm not actually familiar with the internals of IP phones)
The same goes for small managed switches, such as the HP 1810-G8 that happened 
to be on a nearby coworker's desk when I wrote this.

Alex

From: Clyde Wildes (cwildes) 
Sent: Friday, 16 December 2016 7:29 a.m.
To: Alex Campbell
Cc: netmod@ietf.org; Kent Watsen; Juergen Schoenwaelder
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi Alex,

Thanks for your review. My comments are inline as [clyde]…

On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell" 
 wrote:

I am considering to implement the data model in this draft.

I have reviewed this draft and found the following issues. In approximately 
decreasing order of severity:

* In the "selector-facility" choice statement the cases have misleading 
names - the case where no facility is matched is named "facility", and the case 
where specific facilities are matched is named "name". I suggest 
"no-facilities" and "specified-facilities", or similar.

[clyde] I understand your concern and agree. Please see the next answer where I 
have removed the no-facilities case from the model.


* I disagree with the premise of the "no-facilities" case, which is that it 
can be used to disable a log action, according to the description:

 description
"This case specifies no facilities will match when
 comparing the syslog message facility. This is a
 method that can be used to effectively disable a
 particular log-action (buffer, file, etc).";

  If an administrator wants to disable a log action they should do it by 
either removing it from the configuration, or by setting an "enabled" leaf to 
false.
  With that in mind, there is no reason for the "no-facilities" case to 
exist.

[clyde] I agree with your suggestion to simplify by removing the no-facilities 
case. Please see the revised selector grouping which will appear in the next 
draft:

  grouping selector {
description
  "This grouping defines a syslog selector which is used to
   select log messages for the log-action (console, file,
   remote, etc.). Choose one or both of the following:
 facility [ ...]
 pattern-match regular-expression-match-string
   If both facility and pattern-match are specified, both must
   match in order for a log message to be selected.";
container selector {
  description
"This container describes the log selector parameters
 for syslog.";
  list facility-list {
key facility;
description
  "This list describes a collection of syslog
   facilities and severities.";
leaf facility {
  type union {
type identityref {
  base syslogtypes:syslog-facility;
}
type enumeration {
  enum all {
description
  "This enum describes the case where all
   facilities are requested.";
  }
}
  }
  description
"The leaf uniquely identifies a syslog facility.";
}
uses log-severity;
  }
  leaf pattern-match {
if-feature select-match;
type string;
description
  "This leaf desribes a Posix 1003.2 regular expression
   string that can be used to select a syslog message for
   logging. The match is performed on the RFC 5424
   SYSLOG-MSG field.";
  }
}
  }


* What is the behaviour of a selector if neither "no-facilities" nor 
"facility-list" is present?

[clyde] At least one or both of the following must be specified: facility; 
pattern-match (if supported).

I have updated the description at the beginning of the selector – please see 
above.


* In the "selector" grouping it is not clear how the facility and pattern 
conditions are combined to decide whether a message is selected.

  Must they both match the message, or is it sufficient for 

Re: [netmod] "when" statement deviation

[Alex Campbell]

I don't see how a "when" statement modified by a deviation is any more 
complicated to implement than a "when" statement outside of a deviation - 
presuming that augments and deviations are processed before "when" statements.


Alex



From: Andy Bierman 
Sent: Tuesday, 10 January 2017 11:20 a.m.
To: Alex Campbell
Cc: netmod@ietf.org
Subject: Re: [netmod] "when" statement deviation

Hi,

This is not allowed because it is too complicated to implement.
Changing the schema tree based on values of instances within the schema tree
is full of complications.

Note that when-stmt used where allowed enables or disables the schema tree
without changing it. This is hard enough to support.


Andy


On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell 
mailto:alex.campb...@aviatnet.com>> wrote:

Hi,


I have a module that adds some configuration to interfaces (the specific 
feature being configured isn't important here, so I'll just call it "feature").

I want to implement this module, but the device I'm working on only supports 
the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module that says the 
feature configuration is only available for these kinds of interfaces.


However, I found that "when" statements are not allowed to be affected by 
deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


module feature-module {

// ... prefix, imports, etc ...

import ietf-interfaces {prefix if;}


augment /if:interfaces/if:interface {

container feature {

leaf enabled {

type boolean;

description "Enables the feature";

}

}

}

}


module feature-module-deviations {

// ... prefix, imports, etc ...

import feature-module {prefix fm;}

import iana-if-types {prefix ianaift;}


deviation /if:interfaces/if:interface/fm:feature {

deviate add {

// parsing fails here; "when" is not allowed as a child of 
"deviate"

when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type = 
'ianaift:ieee8023adLag'";

}

}

}


Alex


___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod


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

[netmod] "when" statement deviation

[Alex Campbell]

Hi,


I have a module that adds some configuration to interfaces (the specific 
feature being configured isn't important here, so I'll just call it "feature").

I want to implement this module, but the device I'm working on only supports 
the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module that says the 
feature configuration is only available for these kinds of interfaces.


However, I found that "when" statements are not allowed to be affected by 
deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


module feature-module {

// ... prefix, imports, etc ...

import ietf-interfaces {prefix if;}


augment /if:interfaces/if:interface {

container feature {

leaf enabled {

type boolean;

description "Enables the feature";

}

}

}

}


module feature-module-deviations {

// ... prefix, imports, etc ...

import feature-module {prefix fm;}

import iana-if-types {prefix ianaift;}


deviation /if:interfaces/if:interface/fm:feature {

deviate add {

// parsing fails here; "when" is not allowed as a child of 
"deviate"

when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type = 
'ianaift:ieee8023adLag'";

}

}

}


Alex

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

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

[Alex Campbell]

Yes/support

The main issue I have with this draft, that I would like to be addressed at 
some point, is the way it uses heavily restricted lists to model sequences of 
VLAN tags.
It seems to me that something like the following would be much simpler, without 
losing any expressive power, in most cases:

container tags {
  leaf s-vlan {
type dot1q:dot1q-vlan-id;
  }
  leaf c-vlan {
type dot1q:dot1q-vlan-id;
  }
  must "s-vlan or c-vlan";
}

where either or both tags can be specified, and only specified tags are matched 
(so if no c-vlan is specified then c-vlan is irrelevant for matching).

Alternatively, maybe the restrictions relating to tag type and order should be 
removed, so that if I *want* to have an unusual device configuration (such as 
pushing 3 consecutive c-vlan tags) then I am able to do so.

Also, ietf-if-l3-vlan contains a feature (l3-vlan-sub-interfaces) that gates 
everything in the module. This is pointless IMO. If a server doesn't support L3 
vlan subinterfaces then it should not implement the module (whose entire 
purpose is to model L3 vlan subinterfaces).


Alex


From: netmod  on behalf of Lou Berger 

Sent: Tuesday, 13 December 2016 12:31 p.m.
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

All,

This is start of a two week* poll on making
draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group
document.

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

* Given the holiday, the poll ends December 28.

Thank you,
NetMod WG Chairs

___
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] WG Last Call for draft-ietf-netmod-syslog-model-11

[Alex Campbell]

I am considering to implement the data model in this draft.

I have reviewed this draft and found the following issues. In approximately 
decreasing order of severity:

* In the "selector-facility" choice statement the cases have misleading names - 
the case where no facility is matched is named "facility", and the case where 
specific facilities are matched is named "name". I suggest "no-facilities" and 
"specified-facilities", or similar.

* I disagree with the premise of the "no-facilities" case, which is that it can 
be used to disable a log action, according to the description:

 description
"This case specifies no facilities will match when
 comparing the syslog message facility. This is a
 method that can be used to effectively disable a
 particular log-action (buffer, file, etc).";

  If an administrator wants to disable a log action they should do it by either 
removing it from the configuration, or by setting an "enabled" leaf to false.
  With that in mind, there is no reason for the "no-facilities" case to exist.

* What is the behaviour of a selector if neither "no-facilities" nor 
"facility-list" is present?
* In the "selector" grouping it is not clear how the facility and pattern 
conditions are combined to decide whether a message is selected.
  Must they both match the message, or is it sufficient for either one to match 
the message?
* Not all servers have a console; there should be a feature to indicate whether 
logging to the console is supported.
* Likewise, not all servers may support logging to user sessions.
* Likewise, not all servers may support a user-accessible filesystem.
* RFC 5424 states that the severity and protocol values are not normative. 
* It's not clear to me why this needs to be split into two modules. Is it so 
that other modules can define logging parameters but still be usable on a 
device without syslog?
* "log-severity" defines a severity filter, not a severity, so its name is 
misleading.
* Perhaps the "severity" type and the facility identities should have 
"reference" statements referring to RFC 5424, rather than referring to it in 
the description.
* In section "8.2", "admisintrator" is a typo.

I assume that the means of accessing the memory buffer and log files are out of 
scope of this data model.

Alex


From: netmod  on behalf of Kent Watsen 

Sent: Wednesday, 14 December 2016 2:01 p.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

This is a notice to start a two-week NETMOD WG last call for the document:

A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11

Please indicate your support or concerns by Tuesday, December 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

As well as:
  * I have implemented the data model in this draft.
  * I am implementing the data model in this draft.
  * I am considering to implement the data model in this draft.
  * I am not considering to implement the data model in this draft.

Thank you,
NETMOD WG Chairs



___
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] Modelling different "levels" of data in YANG

[Alex Campbell]

IMO using an action or rpc is an okay solution for now, certainly better than 
than not including the data at all.


Perhaps in the future the client could specify which YANG modules it cares 
about, in addition to a subtree filter. Then you could put the extended 
diagnostic information into another module (using "augment"), and clients that 
don't know about the extended diagnostic information wouldn't request it, and 
clients that do would know to only request it when they need it.


The problem also makes me think of ConfD's "hide groups", but it's hard to see 
how those would be extended to support programmatic interfaces.



From: netmod  on behalf of Robert Wilton 

Sent: Wednesday, 7 December 2016 3:58 a.m.
To: Athanasios Kyparlis; netmod@ietf.org
Subject: Re: [netmod] Modelling different "levels" of data in YANG


Hi Athanasios,


Thanks for the suggestion.  As per my reply to Vladimir, I think that this 
solves the question of how to get them, but doesn't really solve the issue of 
how a client is expected to know that they wouldn't be included in a regular 
get request.


Thanks,
Rob


On 05/12/2016 18:25, Athanasios Kyparlis wrote:

Maybe not ideal, but could we use an action or rpc for them?


From: netmod  on 
behalf of Robert Wilton 
Sent: Monday, December 5, 2016 1:10:47 PM
To: netmod@ietf.org
Cc: Peter Jones
Subject: [netmod] Modelling different "levels" of data in YANG

Hi,

We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.

One interesting issue that has come up is the scope of the operational
state data that could be modeled:

At the top level, an operator may just want to know whether an Ethernet
interface is up or down.

At a second level, if the Ethernet interface is down, then there is some
high level diagnostics information that may be useful to an operator to
diagnose why the interface isn't up (e.g. alarms information, optical
power levels, auto-negotiation protocol status).

There is also a third level, of very detailed, 802.3 hardware register
information defined in 802.3 Clause 45.  Such information is probably of
most relevance to the engineers developing and programming Ethernet
chips and PHYs, but is sometimes useful for resolving potential vendor
inter-operation issues.  Retrieving this information out of the Ethernet
chips can be comparatively slow.

The question that was being discussed is whether it is appropriate to
model all three levels on information in the 802.3 Ethernet YANG models,
or whether only the top level and second level information can/should be
modeled via YANG?

If we were to model the third level information in YANG then it would
seem highly desirable for that information to not be returned in
response to a general NETCONF  request because the information is
generally not of relevance and has potential performance issues in
returning it.  Instead, it would seem desirable to only return this data
if it was specifically requested (e.g. a  request on the node
containing the third level information), or if a hypothetical filter
extension was specified and used to explicitly include it in the
response. Given that there doesn't seem to a great way to currently
achieve this in YANG, this makes me think that it isn't sensible to
model this third level of detailed information in YANG at this time.  Do
others agree?

Have others faced similar issues, and if so, how have you solved them?

Input welcome.  Thanks,
Rob


___
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] How to prevent a client from modifying the type of an interface?

[Alex Campbell]

At Aviat we've been using deviations for this:

module aviat-ietf-interfaces-dev {
// ...

deviation "/if:interfaces/if:interface" {
deviate add {
must "if:type = 'ianaift:l2vlan' or if:type = 
'ianaift:ethernetCsmacd'
  or if:type = 'rl:radio-link-terminal' or if:type = 
'rl:carrier-termination'
  or if:type = 'ianaift:ieee8023adLag'";
}
}
}


From: netmod  on behalf of Vladimir Vassilev 

Sent: Wednesday, 30 November 2016 11:05 p.m.
To: Jan Lindblad; netmod@ietf.org
Subject: Re: [netmod] How to prevent a client from modifying the type of an 
interface?

On 11/29/2016 05:18 PM, Jan Lindblad wrote:

> Bart,
>
> Jürgen et al are of course right in what they say, but if you really
> want to use YANG to enable a manager to know a priori what values are
> possible for a particular leaf somewhere, that's easy too -- if you
> see the addition of a new proprietary YANG module as a possibility.
>
> module device-limitations {
> ...
>   container limitations {
> must
> "not(/if:interfaces/if:interface[not(if:type='ianaift:fastdsl')])" {
>   error-message "There must not be any interfaces that are not of
> fastdsl interface type";
> }
>   }
> }
+1. We use the same approach for defining device specific limitations in
YANG.

___
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] New Version Notification for draft-vallin-netmod-alarm-module-00.txt

[Alex Campbell]

Hi,

alarm-list holds a list of raised and cleared alarms (but not those that have 
never been raised).
alarm-inventory holds a list of all possible alarm _types_.
If alarm-inventory were to hold a list of all possible alarms, that would 
indeed resolve my concern. (It would be equivalent to our all-alarms list)

As an example, suppose a server supports a few kinds of resources - interfaces, 
line cards, and timing cards - and the alarm types timing-signal-lost (which 
applies to timing cards) and timing-unsynchronized (which applies to TDM 
interfaces experiencing slips). An operator who is unaware of the distinction 
might configure the management application to send an email if a 
(timing-unsynchronized, TimingCard1) alarm is raised. If the server exported a 
list of all possible alarms, the management application would be able to 
prevent the operator from selecting this combination.

>> * has-clear doesn't need to be a union of only one type
> ?
The type of the leaf "/alarms/alarm-inventory/alarm-type/has-clear" is defined 
as "type union {type boolean;}"
This is redundant as it could simply be "type boolean;"

> I think there is a huge value in this module design that as a client you see 
> the alarm history per alarm not in a separate log.
> As a user you select the interface of a device and you see the current alarm 
> state as well as the history. This is important for trouble-shooting
Agreed.

> But other things than entities can have alarms. AND instance-identifers are 
> not “free-form”. It is a strange limitation to limit alarms to the 
> entity-model
I agree; however, it has the nice effects that it is possible to enumerate all 
resources, and also that the resources and their associated alarms form a 
hierarchy which can be visually displayed - an operator can expand a tree to 
get progressively more detail on the device status.
The top level of the tree shows "device has problems"; the next level shows 
"line card 3 has problems"; the next level shows "Interface 3/2 has problems"; 
the next level shows "Interface 3/2 has no media".
However, I think the concepts of root cause resources and impacted resources 
are more useful than this hierarchy.

> I do not understand when you say "initially populates the alarm list with all 
> possible alarms”.
If the link is up on EthernetPort1, then in this model (link-down, 
EthernetPort1) is a "possible alarm" and not an "actual alarm", while in our 
model it is just an alarm, whose status is "cleared".
I'm not sure about the rest of the networking world, but this is the model 
Aviat devices currently use. If Aviat is the exception here, we can certainly 
adjust our terminology when implementing this module.

> OK, I can work on improved descriptions. They idea is the following.
> As an operator you would like to have *one* alarm although there are several 
> symptoms, rather than having 15 alarms per symptom.
> This module gives you the freedom of selecting should the faulty resource be 
> the alarming object or the impacted resource.
> Both options are available.
> If you raise an alarm on an interface you might say that a VPN is “impacted”
> If you raise an alarm on a VPN due to some probing you can hint the operator 
> on the corresponding interface who might have a bad config
I like this idea, but I'm not sure how the device would determine which alarms 
to raise.
It sounds like an "interface is down" alarm would be raised if an interface 
goes down, *unless* that also causes a VPN to go down?

Alex


From: stefan vallin 
Sent: Friday, 7 October 2016 8:32 p.m.
To: Alex Campbell
Cc: Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] New Version Notification for 
draft-vallin-netmod-alarm-module-00.txt

Hi!
Thanks for your comments!

Several of your comments seems to be that you might not have understood the 
difference between “alarm-list” and “alarm-inventory”
Please read those a bit before seeing my comments
See comments inline


> On 06 Oct 2016, at 00:22, Alex Campbell  wrote:
>
> Hi,
>
> The main issue I have with this draft is that it's there's no way for the 
> operator to get a list of all possible alarms on the device, without 
> device-specific semantic knowledge.
> They can get a list of all alarm *types*, but there's no information that 
> says, for example, that a link-loss alarm can't be raised for a local CPU 
> resource (or indeed, that the local CPU resource even exists).
> This is exacerbated by the ability of operators can delete alarm entries; 
> even if a device initially populates the alarm list with all possible alarms, 
> the operator can still delete some of them, in which case the list no longer 
> reflects all possible alarms.

Re: [netmod] Corrections needed in the draft-ietf-netmod-entity-00

[Alex Campbell]

Hi,


If you are referring to the circular reference in the expresssion 
'derived-from-or-self(../class, "iana-entity", "sensor")', I would rather see 
sensor-data separated into another module than see  entity-physical-class moved 
to iana-entity.

This would be more consistent with the RFC 7223 interface model, where 
interface-type-specific modules augment the basic generic interface module with 
interface-type-specific data.

It also leaves open the possibility of a server not supporting iana-entity if 
it doesn't need any of the standard entity types.


Alex




From: netmod  on behalf of Carey, Timothy (Nokia - US) 

Sent: Friday, 7 October 2016 2:38 a.m.
To: netmod@ietf.org
Subject: [netmod] Corrections needed in the draft-ietf-netmod-entity-00

Hello,

The BBF plans to use the Entity module as one of our common YANG modules within 
the BBF.
The current draft of the module has some errors that we feel need corrected.

Specifically there is a circular reference for the identity 
entity-physical-class; we feel that this should be moved to the 
iana-entity-module.

What does the group think?

BR,
Tim

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

Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt

[Alex Campbell]

Hi,

The main issue I have with this draft is that it's there's no way for the 
operator to get a list of all possible alarms on the device, without 
device-specific semantic knowledge.
They can get a list of all alarm *types*, but there's no information that says, 
for example, that a link-loss alarm can't be raised for a local CPU resource 
(or indeed, that the local CPU resource even exists).
This is exacerbated by the ability of operators can delete alarm entries; even 
if a device initially populates the alarm list with all possible alarms, the 
operator can still delete some of them, in which case the list no longer 
reflects all possible alarms.


We have an internally developed (but not yet published) YANG model for alarms 
which is very similar to this draft model, but with the following key 
differences:
* It does not track past status changes (they are stored in a separate event 
log); it is only concerned with current state.
* Alarms are associated with entities (from ietf-entity.yang) rather than 
arbitrary strings or instance-identifiers.
* It contains a list of all-alarms, regardless of whether they have ever been 
raised. This includes static information (description, severity) as well as 
current state information.
* It contains a separate list of raised-alarms, which mostly duplicates the 
information from all-alarms, but only contains an entry for an alarm if it is 
raised. This allows a subtree filter to retrieve only information about raised 
alarms, but it may be redundant.
* Instead of shelved alarms, we have a simple boolean "disabled" setting for 
each alarm; raised disabled alarms still appear as raised in the all-alarms 
list (with another indication they're disabled), but do not appear in the 
raised-alarms list.

With this model (and because ietf-entity.yang defines a hierarchy of entities) 
it is easy to display a hierarchical view of all entities and their associated 
alarms.

In our model, entries in the all-alarms list can only be added when resources 
are added to the system, and can only be deleted when resources are removed 
from the system.



Other comments:
* is-cleared feels like a double negation (false means "this alarm is not not 
raised"); I would like to see it changed to is-raised
* I would like to see a YANG feature for past status changes, or perhaps this 
part moved to a separate module augmenting ietf-alarms.
* has-clear doesn't need to be a union of only one type
* The meanings of "impacted resource" and "root cause resource" are unclear. 
* "This list is used to shelf alarms" should be "... to shelve alarms"
* "Shelv alarms for ..." should be "Shelve alarms for ..." (multiple 
occurrences)


Alex


From: netmod  on behalf of Martin Bjorklund 

Sent: Thursday, 6 October 2016 1:26 a.m.
To: netmod@ietf.org
Subject: [netmod] New Version Notification for  
draft-vallin-netmod-alarm-module-00.txt

Hi,

We have posted a new version of the alarm module.  The previous
document was called draft-vallin-alarm-yang-module-00, this new
version is called draft-vallin-netmod-alarm-module (hence it is also a
-00).

This updated version incorporates comments on the previous docuement,
and adds support for alarm shelving.

It would be good to know if people in this WG are interested in this
work.


/martin and stefan




A new version of I-D, draft-vallin-netmod-alarm-module-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Name:   draft-vallin-netmod-alarm-module
Revision:   00
Title:  YANG Alarm Module
Document date:  2016-10-05
Group:  Individual Submission
Pages:  58
URL:
https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-vallin-netmod-alarm-module/
Htmlized:   https://tools.ietf.org/html/draft-vallin-netmod-alarm-module-00


Abstract:
   This document defines a YANG module for alarm management.  It
   includes functions for alarm list management, alarm shelving and
   notifications to inform management systems.  There are also RPCs to
   manage the operator state of an alarm and administrative alarm
   procedures.  The module carefully maps to relevant alarm standards.

___
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] How to constrain a leaf to a read-only list of supported values?

[Alex Campbell]

> Dale R. Worley  writes:
>> Ladislav Lhotka  writes:
>>> typedef Compression-Method {
>>>   ...
>>> }
>>>
>>> list node {
>>>   config true;
>>>   key name;
>>>
>>>   string name;
>>>
>>>   leaf-list supported-compression-methods {
>>> type Compression-Method;
>>> config false;
>>>   }
>>>
>>>   Compression-Method compression-method;
>>>   must "compression-method ... supported-compression-methods";
>>> }

>> The only technical problem with your mock-up is that "must" expressions
>> on config nodes cannot refer to state data.

> Ouch!  That means that any technique like the one I proposed isn't going
> to work.  Indeed, it may be that there is no way to constrain a config
> leaf based on value(s) provided by the implementation.

It was my understanding was that this is a deliberate design decision, so that 
a configuration tree can always be validated offline.

> Dale

Alex


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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

[Alex Campbell]

What prevents features from being units of conformance?

From: netmod  on behalf of Juergen Schoenwaelder 

Sent: Friday, 2 September 2016 5:06 a.m.
To: Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported 
values?

On Thu, Sep 01, 2016 at 09:41:04AM -0700, Andy Bierman wrote:
> Hi,
>
> We keep having discussions about YANG conformance related issues.
> The only unit of conformance is the YANG module, so it is possible to
> think the way to solve the conformance/discovery problem is to put every
> definition
> in its own module. This is operationally absurd of course, so someday YANG
> is going to need a real conformance model.
>

Yes.

/js

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

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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Alex Campbell]

The intention in this case is obviously to evaluate the 'must' statement if
the container contains any values; what would break if we said that

   A non-presence container exists in the data tree if and only if it has
   any children which exist in the data tree.

thus disallowing the existence of empty NP-containers in the data tree?


From: netmod  on behalf of Vladimir Vassilev 

Sent: Tuesday, 23 August 2016 7:41 a.m.
To: Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending 
on NP-containers

On 08/22/2016 08:27 PM, Martin Bjorklund wrote:
> Vladimir Vassilev  wrote:
>> On 08/22/2016 06:45 PM, Martin Bjorklund wrote:
>>> I disagree.  If the model needs to have some semantic validation
>>> rules, the designer is going to put them in a place such that they are
>>> evaluated when the need to be evaluated.
>> So designers augmenting /interfaces/interface with non-presence
>> container with child leaves should just pick one of the leaves in YANG
>> 1.1 and put the must statements there instead of the parent
>> container.
> Sorry I can't parse this.  What is "leaves in YANG 1.1"?
Well for example the designer wants to add container with multiple leaf
children (leaves) to /interfaces/interface. Assume there is only 1 of
the 96 interfaces on a switch that can have inet address for the purpose
of managing the device:

augment "/if:interfaces/if:interface" {
 container inet {
 must "../name = 'me0'" {
 description
  "The inet container is only valid for the management
('me0') interface.";
 }
 leaf address {
 type inet:ip-prefix;
 }
 }
}

So in this example the must expression will be evaluated not only for
interfaces the user attempts to create
/interfaces/interface/inet/address but for all those he does not attempt
to create it. This is not the case in YANG 1.0 and this is example how
processing of validation expressions increases in YANG 1.1

In this case the designer can copy the must expression to the address
leaf and it will be evaluated only when the user attempts to create that
leaf ... however when it is not a single leaf in the container the
workaround can get trickier.

>
> My point is that must expressions don't just exist w/o any reason for
> the sake of theoretical arguments.  If there is a YANG 1.1 model with
> a must expression in an NP-container, then there is probably a reason
> for it - the designer wants it to be evaluated if its parent exist.
Well this would be the case in YANG 1.1. In YANG 1.0 the designer wants
it to be evaluated if the non-presence container itself exists not its
parent. Now this changes because of the "clarification" from Y41.
> If we change the rules for when must expressions are evaluated, the
> module designer will have to figure out some other way to add these
> must expressions, and the performance will be the same.  So your
> argument that many must expressions can lead to performance issues is
> not really a problem in itself.
We are changing the rules from YANG 1.0. Auto evaluation of all
non-presence containers must statements is now mandatory when their
parent container exists. I still don't see how there is no problem with
the increased must statement processing and believe there is
misunderstanding somewhere.

Vladimir
>
>
> /martin
>
>> Yes this might work. There is no problem adding extra "../"
>> in the Xpath expressions. But what is the justification of all that
>> except the "If a container does not have a "presence" statement and
>> the last child node is deleted, the NETCONF server MAY delete the
>> container." text?
>>

___
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] OpsState and Schema-Mount

[Alex Campbell]

I think in this case it would make sense to implement both the hypothetical 
standard module's state data (which would be device-agnostic, such as a boolean 
value indicating whether each configured rule is active) and also a 
device-specific module providing access to the more detailed internal state.


From: netmod  on behalf of Ladislav Lhotka 

Sent: Wednesday, 10 August 2016 11:39 p.m.
To: Andy Bierman; Robert Wilton
Cc: netmod WG
Subject: Re: [netmod] OpsState and Schema-Mount

Andy Bierman  writes:

> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>> I don't properly understand the points that you are making, please see
>> clarifying comments/questions inline ...
>>
>> On 08/08/2016 22:51, Andy Bierman wrote:
>>
>>
>>
>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:
>>
>>> Acee writes:
>>> >Then I see no YANG language barriers in collapsing config and state
>>> trees
>>> >- the model root just needs to be “config true”.
>>>
>>> Great, I think we’re all agreed.  Can we now discuss the text I proposed
>>> for 6087bis?  - here’s the link to my proposal:
>>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>>>
>>>
>> IMO this effort to avoid 2 containers is not well thought out.
>> Some concerns:
>>
>> 1) modularity
>> placing the monitoring objects within the configuration means the
>> monitoring
>> cannot be used on its own
>>
>> If it is one module with two top level augments (foo and foo-state) then
>> this problem still exists.  Hence, please can you clarify why converging
>> them on a single root node means that monitoring cannot be used on it own?
>> Wouldn't a device need to use deviations in both cases to strip out the
>> config nodes that they are not supporting?
>>
>>
> Before the "rule" I can choose to place monitoring in its own module
> without any reliance on other modules.  If the monitoring does not
> share indexing, what value is there in putting it in the config tree?
> I see none except a poor attempt at model classification.

Sometimes it may indeed make sense to keep configuration and state data
schemas in different modules. For instance, it may be useful (or even
necessary) to have common configuration but different state data for
different implementations, e.g. when devices use vastly different
internal architectures.

One example are packet filters: while it may be possible to have a
common configuration for Linux nftables and Cisco ACLs, monitoring or
debugging either implementation requires access to what the system is
doing under the hood, i.e. system-specific state data and counters.

Lada

>
>
>
>>
>>
>> 2) access control
>> placing the monitoring data within configuration means the
>> monitoring-only clients
>> need write permission turned on for the nodes they can access for
>> read-only
>> This relies on granular and complex NACM rules which require regular
>> maintenance.
>>
>> Again, I don't quite follow this, in the specific example that I have
>> regarding putting a RIB under a config true NP container, I would have
>> thought that NACM read access would have been sufficient for a
>> monitoring-only client.  Is that not the case?
>>
>
>
> If the monitoring is rooting under config=true nodes, then those config=true
> nodes need to be created somehow.  A client with write access is probably
> required.
>
>
>
>>
>>
>> 3) YANG conformance
>> placing the monitoring data inside the configuration means the
>> configuration
>> will be required for conformance; it is not likely to be just 1 NP
>> container.
>>
>> Similar to my response to the first question, I thought that conformance
>> was done on a per module base, not a per sub-tree basis.  So even if you
>> have top level 'foo' and 'foo-state' as part of the same module don't you
>> run into the same conformance problem?
>>
>>
>>
> Much easier to solve the conformance since /foo-state does not need any
> objects from /foo
> to exist first.  Creating the /foo container means that all config=true
> requirements for
> that container must be implemented (or complex deviations used)
>
>
>>
>> 4) pointless;
>>given that new RPC operations are needed to access applied config, the
>> only data not
>>affected (and moved under the config container anyway) is stuff that
>> does not share
>>the same indexing, or counters which are not part of the opstate
>> problem.
>>
>> Sorry, I don't really follow this one.  The original opstate draft put
>> forward by OpenConfig was asking for both applied-configuration and derived
>> state (e.g. statistics and other state) to be co-located under the same
>> structures.  The original discussions focused on applied configuration, but
>> when this was being discussed more recently the desire for a solution to
>> the co-located derived state was also discussed - which is why both
>> draft-schoenw-netmod-revised-datastores-01 and
>> draft-wilton-netmod-refined-d

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Alex Campbell]

Isn't that exactly what the proposed applied configuration datastore is for?
If a device doesn't allow management stations to create or remove list entries, 
but still creates or removes list entries itself, then it can publish them 
through the applied configuration datastore, while leaving the intended 
configuration datastore empty.  Operational data can be contained inside those 
list entries which exist in the applied configuration store, instead of needing 
a separate tree to contain it.

- Alex






From: netmod  on behalf of Andy Bierman 

Sent: Wednesday, 13 July 2016 4:17 a.m.
To: Lou Berger
Cc: netmod WG
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
mailto:lber...@labn.net>> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.  Why is that progress?


Andy




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

Re: [netmod] YANG library update and new YANG guideline issue

[Alex Campbell]

My preference is not to add schema nodes that are not useful.

If it is foreseen that other nodes will be added in the container then the 
container is fine; otherwise I see no reason to have one.



From: netmod  on behalf of Andy Bierman 

Sent: Thursday, 9 June 2016 12:25 p.m.
To: netmod@ietf.org
Subject: [netmod] YANG library update and new YANG guideline issue

Hi,


We have been asked to make the YANG library module consistent
wrt/ use of a container parent for a list.  We decided to remove the
submodules container parent from the child submodule.
The submodule list and deviation list will now be consistent.

Benoit has asked for a YANG guideline in rfc6087bis on this issue.
I added the issue with an example to github
https://github.com/netmod-wg/rfc6087bis/issues/35

Please comment if you prefer
  (A) guideline is be consistent throughout module (whichever choice)
  (B) guideline is for use of a container parent
  (C) guideline is to not use a container parent
  (D) something else



thanks,
Andy, Martin, and Kent





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

Re: [netmod] update on "rdns" URN for enterprise YANG models

[Alex Campbell]

> From: netmod  on behalf of Ing-Wher (Helen) Chen 
> 
> Sent: Thursday, 21 April 2016 2:40 a.m.
> To: Juergen Schoenwaelder
> Cc: netmod@ietf.org
> Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
> 
> > -Original Message-
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > university.de]
> > Sent: Tuesday, April 19, 2016 2:23 PM
> > To: Ing-Wher (Helen) Chen 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
> >
> > On Tue, Apr 19, 2016 at 04:23:51PM +, Ing-Wher (Helen) Chen wrote:
> > > I'm not an expert on XML namespaces and I'm a little confused by some
> > > of the questions, so I apologize if my response below does not quite
> > > answer the questions.  I'd like to point out that the request for
> > > "rdns" URN is not to prevent the use of URLs. The request for "rdns"
> > > URN is to allow an enterprise to easily create a URN namespace, if the
> > > enterprise happens to prefer to use URN as a YANG module namespace.  I
> > > also think that the problems that arise when a YANG module uses a URN
> > > based on an enterprise's domain name are the same problems that arise
> > > when a YANG module uses a URL based on an enterprise's domain name.
> > > (Of course, this is not an excuse to fix the problems that should be
> > > fixed.)
> >
> > You write "happen to prefer to use URN" - why?

> draft-chen-rdns-urn Section 4 
> 
> discusses why an enterprise might prefer to use URN over URL.  URL provides
> resource access mechanism, which might mislead a customer to request that
> the YANG module be accessible at a specific location.  It's true that the 
> device
> does not care that the YANG module is not at a particular URL, but I can still
> imagine getting a bug requesting that the YANG module be accessible at the 
> URL.

URLs are frequently used as namespaces in XML, without referring to a 
particular resource (and most of them are HTTP URLs that return generic 
error-404 pages).
Does this proposal suggest that YANG namespaces should be treated differently 
from XML namespaces?

> Thanks,
> Helen


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