Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

[Acee Lindem (acee)]

Top posting to assure everyone reads:

I don’t think I could of come up with a better strategy to guarantee that IETF 
YANG models aren’t used if I tried. We’ll still specify them in IETF document 
and they’ll provide a useful reference model for other SDOs and vendor native 
models, but no one is going to implement and deploy them.

Thanks,
Acee

From: netmod  on behalf of Andy Bierman 

Date: Friday, December 9, 2022 at 11:19 AM
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt



On Fri, Dec 9, 2022 at 7:41 AM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:



The idea to encode all relevant semantics of a type in a type's name
has far-reaching consequences:

- Are we going to deprecate counter32 and introduce
  non-zero-based-counter32 because we have also zero-based-counter32?

- Do we introduce date-and-time-with-optional-zone-offset and
  deprecate date-and-time?

I wish we had guiding principles for such naming decisions or, perhaps, it is a 
matter of the type's definition.

The current date-and-time is not ambiguous because it asserts that either a 'Z' 
or an offset is present, making impossible for implementations to assume a 
zoneless form.  Whereas the current ip-address is ambiguous because it silently 
accepts the "without" form, leading to surprise in some implementations when 
the expanded form is "unexpectedly" passed.

Having well-defined guidance could prevent future missteps.




The definition of ip-address (published in 2010) was the right thing
to do since the optional zone index can disambiguate IP addresses in
situations where this is needed. In 2013, we also provided the
ip-address-no-zone definition to be used in situations where there is
never a need to disambiguate IP addresses (e.g., when the zone is
known from the context).


Trying to focus just on this proposal, not extrapolate the trend...

For 10 years we have had 2 typedefs for IP address:

  - ip-address
  - ip-address-no-zone

This should be enough (even without reading the module!) to determine
1 form has a zone, and 1 does not.

But nobody reads the YANG module so they didn't know about ip-address-no-zone.
So how will they know about ip-address-zone either?

Because tooling would flag "ip-address" as deprecated and the description 
statement would say to use the "with-zone" form?


There is no reason to deprecate something to replace it with the exact same 
semantics, but a different name.
The only reason to deprecate something is because it will be removed in the 
future,
Deprecating and obsoleting such a critical data type would be highly disruptive.
Many vendors and SDOs may refuse to do it.




YANG Catalog search shows 1486 modules import the ip-address typedef.
I suspect the number is about twice that.

So we want to tell the world:

"You have to stop using ip-address and use this new type instead".

"Why? What's wrong with it?"

"Nothing. We decided after 13 years we like this name better."

A number of issues were raised (misconfigurations, OpenConfig, etc.).


What are these operational problems that are caused because of the name 
ip-address?
IMO it would be far worse to take away the most important typedef in YANG.

We have never heard any issues at all from customers about problems 
implementing ip-address.
As Martin pointed out, the server MUST check for values such as 0.0.0.0 that are
accepted by the typedef pattern but not the leaf semantics. Checking for a zone 
index
is no different.  The ip-address typedef has been clarified in the draft 
update.  That is sufficient.





Kent // contributor



Andy

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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

[Acee Lindem (acee)]

From: netmod  on behalf of Andy Bierman 

Date: Wednesday, December 7, 2022 at 10:48 PM
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt



On Wed, Dec 7, 2022 at 7:02 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:

>> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the
>> most disruptive
>> change to YANG that one could make.

No, the most disruptive thing would be to do what roughly 1/2 of the WG was 
proposing before, which is to introduce now a non-backwards compatible change 
in the existing definitions, which would immediately break all legacy uses.


>> A type name cannot be changed.

Nothing of the sort is being proposed here.


>> A new name can be introduced so there are 2 types that do the same thing.
>> IMO this will increase the overall confusion, and not help in any way.

We are addressing the current/existing confusion, as discussed in the last 9 
months and in a virtual interim.  Not doing anything would be truly unhelpful.

The strategy is to gradually move towards having only explicit names.   The 
first step is to introduce a new explicit name, while deprecating the legacy 
ambiguous name.  This provides time for modules to slowly migrate to the new 
name.  The second step, to be done only after the "versioning" work lands, is 
to remove the legacy deprecated name, while marking the module revision as 
having an NBC change.

IMO there is no operational problem to fix.
It is too late to change the names of the IP addresses with zones.
It is not a real problem because the server is still responsible for
accepting or sending the zone index (just like address 0.0.0.0).

For data types where the zone is never supposed to be allowed may need to
change to the no-zone variant.

Redoing all YANG modules that use the (proposed) deprecated ip-address
to some other type name is very disruptive and not needed.

I agree – this is the “cut the baby in half” option.

Acee


Andy

Between the two steps is when there may be confusion but even then, not really, 
if tooling properly warns about deprecated nodes.


Kent // contributor

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

Re: [netmod] The NETMOD WG has placed draft-dbb-netmod-acl in state "Candidate for WG Adoption"

[Acee Lindem (acee)]

NETMOD WG,

From: netmod  on behalf of Mahesh Jethanandani 

Date: Tuesday, December 6, 2022 at 6:58 PM
To: "netmod-cha...@ietf.org" 
Cc: netmod 
Subject: Re: [netmod] The NETMOD WG has placed draft-dbb-netmod-acl in state 
"Candidate for WG Adoption"

Is this in-lieu of a call for adoption, or did I somehow miss the call for 
adoption? I do see a separate IPR call.

Either ways, I do support the work, whether as a separate draft or as a bis of 
the original work. Would have preferred the latter, if not for anything else 
but to see how a YANG model can be updated in IETF.

This is a separate draft. I would be opposed to a BIS of RFC 8519. While the 
new capabilities are useful, I doubt anyone is going to implement them any time 
soon so let’s not complicate RFC 8519.

Thanks,
Acee

Cheers.


On Dec 5, 2022, at 2:41 PM, IETF Secretariat 
mailto:ietf-secretariat-re...@ietf.org>> wrote:


The NETMOD WG has placed draft-dbb-netmod-acl in state
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/


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


Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] [yang-doctors] Length on keys in YANG

[Acee Lindem (acee)]

Jeff,

From: Jeff Haas 
Date: Wednesday, October 5, 2022 at 10:25 AM
To: Acee Lindem 
Cc: Ladislav Lhotka , tom petch , 
"netmod@ietf.org" , YANG Doctors 
Subject: Re: [yang-doctors] [netmod] Length on keys in YANG

Acee,



On Oct 5, 2022, at 10:18 AM, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

It may even be a matter of having a few useful typedefs:

yang-key32 (length 1..32)
yang-key64 (length 1..64)
yang-key128 (length 1..128)
yang-key256 (length 1..256)

I agree in principle. Why wouldn’t these be string32, etc, since the leaves in 
question are of type string. We don’t need “yang-“ since they will be prefixed 
with “yang-types:” or some other module.

I'm supremely uninterested in the color of the bike shed. :-)  I find minor 
value is having the word "key" present to cover the use case, but certainly 
could see use cases where a leaf might also want to limit the content size to 
some well known sizes.

This was exactly my point. No need to get defensive.

Acee

While I certainly could be the one that authors the underlying draft, there are 
many who are more deeply involved in daily YANG work that are probably more 
appropriate parties.  Mostly, I'm hoping this discussion gets someone 
interested enough to write the trivial draft and hopefully start socializing it 
in IETF YANG draft reviews.



-- Jeff

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

Re: [netmod] [yang-doctors] Length on keys in YANG

[Acee Lindem (acee)]

Hi Jeff,

From: yang-doctors  on behalf of Jeff Haas 

Date: Wednesday, October 5, 2022 at 9:53 AM
To: Ladislav Lhotka 
Cc: tom petch , "netmod@ietf.org" , YANG 
Doctors 
Subject: Re: [yang-doctors] [netmod] Length on keys in YANG

Lada,


On Oct 5, 2022, at 7:03 AM, Ladislav Lhotka 
mailto:ladislav.lho...@nic.cz>> wrote:

I would still be against setting a hard limit in YANG itself, primarily because 
it is not clear what this general limit should be. Module authors might of 
course consider restricting key length to something that is appropriate for a 
particular key leaf.

IETF doesn't have to formally impose upper limits via language constraint.  
This is more a matter of establishing reasonable best practices and minimal 
tooling for such.

It may even be a matter of having a few useful typedefs:

yang-key32 (length 1..32)
yang-key64 (length 1..64)
yang-key128 (length 1..128)
yang-key256 (length 1..256)

I agree in principle. Why wouldn’t these be string32, etc, since the leaves in 
question are of type string. We don’t need “yang-“ since they will be prefixed 
with “yang-types:” or some other module.

Thanks,
Acee

The usual quote I cite for these sort of things is, "constants are usually 
wrong".  We ran into this in various VPN MIBs and that caused my implementation 
interesting grief when the key, a vrf name, was artificially constrained to be 
shorter than what our implementation permitted.  In MIBs, you were stuck.  In 
YANG, when necessary, you could deviate.

However, in picking some possibly "reasonable" length, we at least call out to 
module reviewers that:
- The key should be of limited size.
- Pay attention... is this long enough?

-- Jeff

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

Re: [netmod] usage of ip-address in openconfig

[Acee Lindem (acee)]

Hi Andy,

I like this suggestion.

From: Andy Bierman 
Date: Wednesday, April 20, 2022 at 9:19 PM
To: Acee Lindem 
Cc: Juergen Schoenwaelder , NetMod WG 

Subject: Re: [netmod] usage of ip-address in openconfig



On Wed, Apr 20, 2022 at 4:02 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:


On 4/20/22, 6:35 PM, "netmod on behalf of Jürgen Schönwälder" 
mailto:netmod-boun...@ietf.org> on behalf of 
j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

On Wed, Apr 20, 2022 at 02:51:35PM -0700, Andy Bierman wrote:
> On Wed, Apr 20, 2022 at 2:34 PM Jürgen Schönwälder <
> 
j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
>
> > I am not sure it helps to look at individual data models but since
> > openconfig is often presented as getting things right, here is what I
> > find in openconfig-system-logging.yang
> >
> Not sure why this missing feature is relevant.

I suggest that people questioning the need to support scoped IPv6
addresses in IETF YANG data models write an I-D explaining why IETF
YANG data models do not need to support scoped IPv6 addresses and pass
the I-D through the IPv6 working group.

The question is not whether there is a single use case for IPv6 link local 
addresses with a zone. The question is whether the base pattern for IPv6 
addresses should include a zone and whether one was expected for all the 
existing YANG model usages of inet:ipv6-address. I think that given the very 
narrow scope, the answer is clearly no.  Additionally, the zone is only 
applicable to IPv6 link-local addresses yet the pattern in RFC 6991 allows the 
zone for ALL IPv6 addresses. This is also clearly wrong.


I think Martin's original comment about 0.0.0.0 applies here as well.
The pattern cannot be trusted to validate a client-provided IP address.
It accepts all possible variants, including some invalid variants.

It is always the server responsibility to validate the client input for the 
specific data node.
Just reject all zone index variants from the client and ip-address == 
ip-address-no-zone.

As Martin suggested, this could fixed in RFC 6991BIS with an update to the 
descriptions that says, in effect, that zone index is not necessarily valid and 
will be rejected by most servers. However, it is a shame that it can’t be 
removed for IPv4 since there are no known use cases or usages.


If the argument is that a zone index is always allowed (even if the usage is 
limited)
then why does the ip-address-no-zone typedef exist at all?  There are no YANG 
guidelines
for picking between them.

Totally agree. In fact, we should cease with the discussion that we use the 
obscure ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone 
types in our IETF YANG models rather than the well-known types.

Thanks,
Acee


Andy






Do you at least admit that IPv4 link-scoped addresses with zone have no useful 
purpose? Or are you going to try and argue that the ever-popular 
169.254.0.0/16<http://169.254.0.0/16> addresses are an absolute requirement for 
YANG models and expected for every usage of inet:ipv4-address?

Acee
P.S. I would add that it is a good thing that syslog server can't be mapped to 
a link-local address with a zone in the Open-Config model. In general, IPv6 
services such as syslog servers should be mapped to global IPv6 addresses.


/js

--
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

___
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

Re: [netmod] usage of ip-address in openconfig

[Acee Lindem (acee)]

On 4/20/22, 6:35 PM, "netmod on behalf of Jürgen Schönwälder" 
 
wrote:

On Wed, Apr 20, 2022 at 02:51:35PM -0700, Andy Bierman wrote:
> On Wed, Apr 20, 2022 at 2:34 PM Jürgen Schönwälder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > I am not sure it helps to look at individual data models but since
> > openconfig is often presented as getting things right, here is what I
> > find in openconfig-system-logging.yang
> >
> Not sure why this missing feature is relevant.

I suggest that people questioning the need to support scoped IPv6
addresses in IETF YANG data models write an I-D explaining why IETF
YANG data models do not need to support scoped IPv6 addresses and pass
the I-D through the IPv6 working group.

The question is not whether there is a single use case for IPv6 link local 
addresses with a zone. The question is whether the base pattern for IPv6 
addresses should include a zone and whether one was expected for all the 
existing YANG model usages of inet:ipv6-address. I think that given the very 
narrow scope, the answer is clearly no.  Additionally, the zone is only 
applicable to IPv6 link-local addresses yet the pattern in RFC 6991 allows the 
zone for ALL IPv6 addresses. This is also clearly wrong. 

Do you at least admit that IPv4 link-scoped addresses with zone have no useful 
purpose? Or are you going to try and argue that the ever-popular 169.254.0.0/16 
addresses are an absolute requirement for YANG models and expected for every 
usage of inet:ipv4-address? 

Acee
P.S. I would add that it is a good thing that syslog server can't be mapped to 
a link-local address with a zone in the Open-Config model. In general, IPv6 
services such as syslog servers should be mapped to global IPv6 addresses. 


/js

-- 
Jürgen Schönwälder  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] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Hi Andy,

From: Andy Bierman 
Date: Thursday, April 14, 2022 at 12:24 PM
To: Acee Lindem 
Cc: Martin Björklund , Juergen Schoenwaelder 
, "l...@ietf.org" , 
"netmod@ietf.org" 
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
While RFC 4001 really didn't need to extend the zone index to IPv4, the 
conversation also pertains to IPv6 address types. At least RFC 4001 got it 
right by not making the zone index part of the default types and defining ipv4z 
and ipv6z.

So is this a correct summary:

 - zone index is not used in IPv4 at all

I’d be fairly certain that this is the case.

 - zone index is not configured by a client in IPv6 at all

Nobody can point to any clients. However, Jürgen has pointed out that there are 
Linux files and commands that accept a link-local addresses with a zone. 
Conceivably, one could extrapolate this to a YANG model.

Thanks,
Acee

 - zone index is assigned by the system (as needed) to IPv6 link-local addresses

I want to add a server option in our code to always reject (or alter)
an edit that contains a zone index.  I need to know the consensus on
whether it is OK to ignore a zone index from a client.
Nothing in RFC 6241 suggests that this is OK for .


Thanks,
Acee

Andy

On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund" 
mailto:lsr-boun...@ietf.org> on behalf of 
mbj+i...@4668.se<mailto:mbj%2bi...@4668.se>> wrote:

I thought the discussion was only about ipv4?


/martin


Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
> On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote:
> > Hi,
> >
> > First of all, I agree that if we were to design this from scratch, I
> > think we should have a type for just an ip address, and use a second
> > leaf for the zone (or interface).
> >
>
> The notation 'fe80::4d9:ff04:4fa6:7980%en0' is widely supported in
> application space. The IPv6 working group has a recurring debate on
> the usage of zoned IPv6 address in URLs [1], where the debate is about
> the question whether the % needs to be escaped or not. I do not know
> where the latest iteration stopped, but details can be found in RFC
> 6874 and draft-carpenter-6man-rfc6874bis-03.
>
> Philip Homburg's RIPE Labs note [2] might also be an interesting
> read. According to this, getaddrinfo() actually deals with zoned
> addresses (and hence even data model implementation that pass data to
> getaddrinfo() to obtain socket addresses may do the right thing.)
>
> My view is that down in the network layer models, you often know the
> interface by context and ipv6-address-no-zone is sufficient. If you go
> to application space, you really want "ipv6-address-with-zone" by
> default in order to support link-local addresses.
>
> /js
>
> [1] http://[fe80::4d9:ff04:4fa6:7980%en0]/
>
> [2] 
https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/
>
> --
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

___
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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

While RFC 4001 really didn't need to extend the zone index to IPv4, the 
conversation also pertains to IPv6 address types. At least RFC 4001 got it 
right by not making the zone index part of the default types and defining ipv4z 
and ipv6z. 

Thanks,
Acee

On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund" 
 wrote:

I thought the discussion was only about ipv4?


/martin


Jürgen Schönwälder  wrote:
> On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote:
> > Hi,
> > 
> > First of all, I agree that if we were to design this from scratch, I
> > think we should have a type for just an ip address, and use a second
> > leaf for the zone (or interface).
> >
> 
> The notation 'fe80::4d9:ff04:4fa6:7980%en0' is widely supported in
> application space. The IPv6 working group has a recurring debate on
> the usage of zoned IPv6 address in URLs [1], where the debate is about
> the question whether the % needs to be escaped or not. I do not know
> where the latest iteration stopped, but details can be found in RFC
> 6874 and draft-carpenter-6man-rfc6874bis-03.
> 
> Philip Homburg's RIPE Labs note [2] might also be an interesting
> read. According to this, getaddrinfo() actually deals with zoned
> addresses (and hence even data model implementation that pass data to
> getaddrinfo() to obtain socket addresses may do the right thing.)
> 
> My view is that down in the network layer models, you often know the
> interface by context and ipv6-address-no-zone is sufficient. If you go
> to application space, you really want "ipv6-address-with-zone" by
> default in order to support link-local addresses.
> 
> /js
> 
> [1] http://[fe80::4d9:ff04:4fa6:7980%en0]/
> 
> [2] 
https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/
> 
> -- 
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

From: netmod  on behalf of Andy Bierman 

Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch 
Cc: "l...@ietf.org" , "netmod@ietf.org" , "Rob 
Wilton (rwilton)" 
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Wed, Apr 13, 2022 at 2:22 AM tom petch 
mailto:ie...@btconnect.com>> wrote:
From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Rob Wilton (rwilton) 
mailto:40cisco@dmarc.ietf.org>>
Sent: 11 April 2022 18:06

Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.


The core issue: how important is it to have the typedefs align with user 
expectations?
The reason the ip-address typedef has been misused is because most people 
thought they knew
what an IP address was already.  They thought the 1000s of examples of IP 
addresses they had seen
were enough. They copied "inet:ip-address" from another YANG module they found, 
never even reading ietf-inet-types.yang.

There are lots of different SDOs creating YANG modules. Not just IETF and 
OpenConfig.
Vendors need to deal with the integration themselves.
Misalignment at the data type level, especially something as important as 
ip-address, is causing problems.

Pretending the data types are aligned is not an optimal solution.
Churning 100 or so YANG modules to use ip-address-no-zone is easier said than 
done.
IMO this is the hardest proposal to execute.

I totally agree. It is 2022 now and the world has evolved to be all about 
experiences. The NETMOD WG should be more concerned about the IETF YANG 
experience than our pedantic backward compatibility rules. Don’t get me wrong, 
these have their place but as Andy has articulated, in this case everyone 
expects the ip-address types to be the ip-addresses we all know and love. Are 
we going to let them down? I certainly hope not!!!

Thanks,
Acee


Andy


Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.




As is sometimes the case with the processes of the IETF, this ignores any 
issues of transition.  I have pointed out a significant number of WG that have 
modules in I-D which include no-zone, in various states, perhaps increasing 
your figures by an order of magnitude.  What are you going to do with I-D e.g. 
in the RFC Editor queue?  Haul them back?

I think that the plan below is a bad one.  I would introduce types with zone - 
that is a no-brainer - but would deprecate the existing types.

Tom Petch

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to implement 
it.  I don't find that argument compelling, at least not with the current 
definition of ip-address in RFC 6991.  I see a clear difference between a type 
defined with an incomplete regex that may allow some invalid values and a type 
that is explicitly defined to included additional values in the allowable value 
space.  Further, I believe that a client just looking at the YANG module could 
reasonably expect a server that implements a data node using ip-address would 
be expected to support IP zones, where they are meaningful, or otherwise they 
should deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Jürgen - I'm not sure how you could extrapolate the basic requirement for IPv6 
link-local addresses to support for YANG configuration support of link-local 
addresses with zone indexes... 

Acee

On 4/12/22, 11:06 AM, "Jürgen Schönwälder" 
 wrote:

Acee,

if you believe link local addresses do not exist or do not need to be
supported, then you may want to bring the news to other WGs.

/js

On Tue, Apr 12, 2022 at 02:54:16PM +0000, Acee Lindem (acee) wrote:
> That was a hypothetical example based on IPv6 Link Local addresses - not 
one anyone has implemented or deployed. 
> Thanks,
> Acee
> 
> On 4/12/22, 10:47 AM, "Joel M. Halpern"  wrote:
> 
> Juergen posted an example of where ip-address is used and zones are 
> expected.
> 
> Yours,
> Joel
    > 
> On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:
> > Joel,
> > 
> > There are plenty of examples of where the ip-address types are used 
and a zone is not accepted. Show me the examples where it is expected? I do 
have reason to believe there aren't any significant usages of the ip-address 
types where zone is accepted. Show me the models
> > 
> > Acee
> > 
> > On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" 
 wrote:
> > 
> >  Do we have reason to believe that no one outside the IETF has 
used
> >  ip-address as we published in ways that need a zone?
> > 
> >  It seems to me that the first step in the plan below is 
reasonable.  But
> >  changing ip-address itself seems a bad idea.  If one means 
no-zone, use
> >  the -no-zone typedef.
> > 
> >  Yours,
> >  Joel
> > 
> >  On 4/11/2022 1:28 PM, Andy Bierman wrote:
> >  >
> >  >
> >  > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
> >  > mailto:40cisco@dmarc.ietf.org>>
> >  > wrote:
> >  >
> >  > Hi all,
> >  >
> >  > Thanks for the comments on this thread so far.  It would 
be nice if
> >  > we are able to come to some sort of rough consensus to a 
solution.
> >  >
> >  > I think that there is consensus that the YANG type 
ip-address (and
> >  > the v4/v6 versions) are badly named as the prominent 
default type
> >  > name has been given to the unusual variant of including 
zone
> >  > information.
> >  >
> >  > Based on the comments on this thread, it also seems 
likely to me
> >  > that most of the usages of ip-address in YANG RFCs is 
likely to be
> >  > wrong, and the intention was that IP addresses without 
zones was
> >  > intended.  At a rough count, of the published RFC YANG 
models at
> >  > github YangModels/standard/ietf/RFC/ to be:
> >  >  86 uses of ip-address
> >  >  68 uses of ipv4-address
> >  >  66 uses of ipv6-address
> >  >
> >  >  1 use of ip-address-no-zone
> >  >  4 uses of ipv4-address-no-zone
> >  >  4 uses of ipv6-address-no-zone
> >  >
> >  > These types appear in 49 out of the 141 YANG modules 
published in
> >  > RFCs.  At a quick guess/check it looks like these 49 
YANG modules
> >  > may appear in 40-50 RFCs.
> >  >
> >  > As mentioned previously, it is also worth comparing this 
to the
> >  > OpenConfig YANG modules:
> >  > They have redefined ip-address (and v4/v6 variants) to 
exclude zone
> >  > information and have defined separate types include zone 
information.
> >  > There are no explicit uses of the "-zoned" variants of 
OpenConfig IP
> >  > addresses in the latest OpenConfig github repository.  
However,
> >  > approximately a third of the IP address types are still 
to the
> >  > ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in
> > 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

That was a hypothetical example based on IPv6 Link Local addresses - not one 
anyone has implemented or deployed. 
Thanks,
Acee

On 4/12/22, 10:47 AM, "Joel M. Halpern"  wrote:

Juergen posted an example of where ip-address is used and zones are 
expected.

Yours,
Joel

On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:
> Joel,
> 
> There are plenty of examples of where the ip-address types are used and a 
zone is not accepted. Show me the examples where it is expected? I do have 
reason to believe there aren't any significant usages of the ip-address types 
where zone is accepted. Show me the models
> 
> Acee
> 
> On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" 
 wrote:
> 
>  Do we have reason to believe that no one outside the IETF has used
>  ip-address as we published in ways that need a zone?
> 
>  It seems to me that the first step in the plan below is reasonable.  
But
>  changing ip-address itself seems a bad idea.  If one means no-zone, 
use
>  the -no-zone typedef.
> 
>  Yours,
>  Joel
> 
>  On 4/11/2022 1:28 PM, Andy Bierman wrote:
>  >
>  >
>  > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
>  > mailto:40cisco@dmarc.ietf.org>>
>  > wrote:
>  >
>  > Hi all,
>  >
>  > Thanks for the comments on this thread so far.  It would be 
nice if
>  > we are able to come to some sort of rough consensus to a 
solution.
>  >
>  > I think that there is consensus that the YANG type ip-address 
(and
>  > the v4/v6 versions) are badly named as the prominent default 
type
>  > name has been given to the unusual variant of including zone
>  > information.
>  >
>  > Based on the comments on this thread, it also seems likely to 
me
>  > that most of the usages of ip-address in YANG RFCs is likely 
to be
>  > wrong, and the intention was that IP addresses without zones 
was
>  > intended.  At a rough count, of the published RFC YANG models 
at
>  > github YangModels/standard/ietf/RFC/ to be:
>  >  86 uses of ip-address
>  >  68 uses of ipv4-address
>  >  66 uses of ipv6-address
>  >
>  >  1 use of ip-address-no-zone
>  >  4 uses of ipv4-address-no-zone
>  >  4 uses of ipv6-address-no-zone
>  >
>  > These types appear in 49 out of the 141 YANG modules published 
in
>  > RFCs.  At a quick guess/check it looks like these 49 YANG 
modules
>  > may appear in 40-50 RFCs.
>  >
>  > As mentioned previously, it is also worth comparing this to the
>  > OpenConfig YANG modules:
>  > They have redefined ip-address (and v4/v6 variants) to exclude 
zone
>  > information and have defined separate types include zone 
information.
>  > There are no explicit uses of the "-zoned" variants of 
OpenConfig IP
>  > addresses in the latest OpenConfig github repository.  However,
>  > approximately a third of the IP address types are still to the
>  > ietf-inet-types.yang rather than openconfig-inet-types.yang, 
so in
>  > theory some of those 58 entries could still intentionally be
>  > supporting zoned IP addresses, but I would expect that the vast
>  > majority would not.
>  > I do see some strong benefit if this basic type being defined 
in the
>  > same way in both IETF and OC YANG, and I believe that the OC 
folks
>  > have got the definition right.
>  >
>  > I see that some are arguing that the zone in the ip-address
>  > definition is effectively optional, and implementations are not
>  > really obliged to implement it.  I don't find that argument
>  > compelling, at least not with the current definition of 
ip-address
>  > in RFC 6991.  I see a clear difference between a type defined 
with
>  > an incomplete regex that may allow some invalid values and a 
type
>  > that is explicitly defined to included additional values in the
>  > allowable value space.  Further, I believe that a client just
&

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Joel, 

There are plenty of examples of where the ip-address types are used and a zone 
is not accepted. Show me the examples where it is expected? I do have reason to 
believe there aren't any significant usages of the ip-address types where zone 
is accepted. Show me the models 

Acee

On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern"  wrote:

Do we have reason to believe that no one outside the IETF has used 
ip-address as we published in ways that need a zone?

It seems to me that the first step in the plan below is reasonable.  But 
changing ip-address itself seems a bad idea.  If one means no-zone, use 
the -no-zone typedef.

Yours,
Joel

On 4/11/2022 1:28 PM, Andy Bierman wrote:
> 
> 
> On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) 
> mailto:40cisco@dmarc.ietf.org>> 
> wrote:
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if
> we are able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and
> the v4/v6 versions) are badly named as the prominent default type
> name has been given to the unusual variant of including zone
> information.
> 
> Based on the comments on this thread, it also seems likely to me
> that most of the usages of ip-address in YANG RFCs is likely to be
> wrong, and the intention was that IP addresses without zones was
> intended.  At a rough count, of the published RFC YANG models at
> github YangModels/standard/ietf/RFC/ to be:
>  86 uses of ip-address
>  68 uses of ipv4-address
>  66 uses of ipv6-address
> 
>  1 use of ip-address-no-zone
>  4 uses of ipv4-address-no-zone
>  4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in
> RFCs.  At a quick guess/check it looks like these 49 YANG modules
> may appear in 40-50 RFCs.
> 
> As mentioned previously, it is also worth comparing this to the
> OpenConfig YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the
> ietf-inet-types.yang rather than openconfig-inet-types.yang, so in
> theory some of those 58 entries could still intentionally be
> supporting zoned IP addresses, but I would expect that the vast
> majority would not.
> I do see some strong benefit if this basic type being defined in the
> same way in both IETF and OC YANG, and I believe that the OC folks
> have got the definition right.
> 
> I see that some are arguing that the zone in the ip-address
> definition is effectively optional, and implementations are not
> really obliged to implement it.  I don't find that argument
> compelling, at least not with the current definition of ip-address
> in RFC 6991.  I see a clear difference between a type defined with
> an incomplete regex that may allow some invalid values and a type
> that is explicitly defined to included additional values in the
> allowable value space.  Further, I believe that a client just
> looking at the YANG module could reasonably expect a server that
> implements a data node using ip-address would be expected to support
> IP zones, where they are meaningful, or otherwise they should
> deviate that data node to indicate that they don't conform to the 
model.
> 
> We also need to be realistic as to what implementations will do. 
> They are not going to start writing code to support zones just
> because they are in the model.  They will mostly reject IP addresses
> with zone information.  Perhaps some will deviate the type to
> ip-address-no-zone, but probably most won't.
> 
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel
> at all appealing.  This would take a significant amount of
> time/effort and I think that we will struggle to find folks who are
> willing to do this.  Although errata could be used to point out the
> bug, then can't be used to fix it, all the errata would be "hold for
> document update" at best.  Further, during the time that it would
> take us to fix it, it is plausible that more incorrect usages of
> ip-address will likely occur (but perhaps could be policed via
> 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

From: netmod  on behalf of Andy Bierman 

Date: Tuesday, April 12, 2022 at 4:54 AM
To: Martin Björklund 
Cc: "l...@ietf.org" , NetMod WG , Robert Wilton 

Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
Hi,

Here's another suggestion.  We keep the ip-address pattern as is, but
document in the description that implementations do not have to
support the optional zone index.  This would essentially document the
behavior of most current implementations.  (This is actually what I
suggested in the earliest thread on this topic that I could find:
https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-fRb2hVsf4sPuCU)



The point of the 2 year warning is to allow anybody using ip-address
and really wants a zone index to move to the (new) ip-address-with-zone typedef 
instead.
It has yet to be shown that this subset is not empty.

This is better than making an NBC change with no warning.
If people did not bother to read the typedef, why would they read the warning?
This is also true, but no different than C programmers who ignore gcc warnings.

Is the NBC change needed at all? Maybe not.
It would be better in the long term to align with OpenConfig and with 99 - 100%
of the implementations. The standards are a means to an end. Nothing more.
If 99 - 100% of the implementations are already doing what is needed,
then it would be a bad idea to disrupt that for the sake of standards purity.

I agree totally. What advantage do we gain but not making the pattern correct 
other than not having to admit it was wrong in the first place?

Thanks,
Acee



/martin

Andy



"Rob Wilton \(rwilton\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:
> Hi all,
>
> Thanks for the comments on this thread so far.  It would be nice if we are 
> able to come to some sort of rough consensus to a solution.
>
> I think that there is consensus that the YANG type ip-address (and the v4/v6 
> versions) are badly named as the prominent default type name has been given 
> to the unusual variant of including zone information.
>
> Based on the comments on this thread, it also seems likely to me that most of 
> the usages of ip-address in YANG RFCs is likely to be wrong, and the 
> intention was that IP addresses without zones was intended.  At a rough 
> count, of the published RFC YANG models at github 
> YangModels/standard/ietf/RFC/ to be:
>   86 uses of ip-address
>   68 uses of ipv4-address
>   66 uses of ipv6-address
>
>   1 use of ip-address-no-zone
>   4 uses of ipv4-address-no-zone
>   4 uses of ipv6-address-no-zone
>
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
> quick guess/check it looks like these 49 YANG modules may appear in 40-50 
> RFCs.
>
> As mentioned previously, it is also worth comparing this to the OpenConfig 
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone 
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP 
> addresses in the latest OpenConfig github repository.  However, approximately 
> a third of the IP address types are still to the ietf-inet-types.yang rather 
> than openconfig-inet-types.yang, so in theory some of those 58 entries could 
> still intentionally be supporting zoned IP addresses, but I would expect that 
> the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way 
> in both IETF and OC YANG, and I believe that the OC folks have got the 
> definition right.
>
> I see that some are arguing that the zone in the ip-address definition is 
> effectively optional, and implementations are not really obliged to implement 
> it.  I don't find that argument compelling, at least not with the current 
> definition of ip-address in RFC 6991.  I see a clear difference between a 
> type defined with an incomplete regex that may allow some invalid values and 
> a type that is explicitly defined to included additional values in the 
> allowable value space.  Further, I believe that a client just looking at the 
> YANG module could reasonably expect a server that implements a data node 
> using ip-address would be expected to support IP zones, where they are 
> meaningful, or otherwise they should deviate that data node to indicate that 
> they don't conform to the model.
>
> We also need to be realistic as to what implementations will do.  They are 
> not going to start writing code to support zones just because they are in the 
> model.  They will mostly reject IP addresses with zone information.  Perhaps 
> some will deviate the type to ip-address-no-zone, but probably most won't.
>
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
> appealing.  This would take a significant amount of time/effort and I think 
> that we will 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Speaking as WG member inline.

From: netmod  on behalf of Andy Bierman 

Date: Monday, April 11, 2022 at 1:28 PM
To: "Rob Wilton (rwilton)" 
Cc: "l...@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.

Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to implement 
it.  I don't find that argument compelling, at least not with the current 
definition of ip-address in RFC 6991.  I see a clear difference between a type 
defined with an incomplete regex that may allow some invalid values and a type 
that is explicitly defined to included additional values in the allowable value 
space.  Further, I believe that a client just looking at the YANG module could 
reasonably expect a server that implements a data node using ip-address would 
be expected to support IP zones, where they are meaningful, or otherwise they 
should deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations will do.  They are not 
going to start writing code to support zones just because they are in the 
model.  They will mostly reject IP addresses with zone information.  Perhaps 
some will deviate the type to ip-address-no-zone, but probably most won't.

The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
appealing.  This would take a significant amount of time/effort and I think 
that we will struggle to find folks who are willing to do this.  Although 
errata could be used to point out the bug, then can't be used to fix it, all 
the errata would be "hold for document update" at best.  Further, during the 
time that it would take us to fix it, it is plausible that more incorrect 
usages of ip-address will likely occur (but perhaps could be policed via 
scripted checks/warnings).


I still feel the right long-term solution here is to get to a state where the 
"ip-address" type means what 99% of people expect it to mean, i.e., excluding 
zone information.

Given the pushback on making a single non-backwards compatible change to the 
new definition, I want to ask whether the following might be a possible path 
that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the 
-no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many implementations are 
unlikely to accept zone information in most scenarios (i.e., so the description 
of the type more accurately reflects reality).
- A new ip-address-with-zone type has been introduced to use where zoned IP 
addresses are required/useful, and models that use ip-address with the 
intention of supporting zoned IP addresses MUST migrate to ip-address-with-zone.
- In the future (at least 2 years after RFC 6991 bis is published), the 
expectation is that the definition of ip-address 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

See inline. 

On 4/11/22, 5:13 AM, "tom petch"  wrote:

From: Lsr  on behalf of Reshad Rahman 

Sent: 10 April 2022 21:42

Inline.

On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee) 
 wrote:


Hi Chris (as WG member),

On 4/5/22, 10:47 AM, "Christian Hopps" 
mailto:cho...@chopps.org>> wrote:



> On Apr 5, 2022, at 09:48, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
>
> [wg-member]
>
> The thing is that most of the existing RFCs use inet:ip-address 
rather inet:ip-address-no-zone. It would be better to if we could fix 
inet:ip-address in RFC 6991 BIS to not include the zone similar to what was 
done in the MIB (RFC 4001). However, we're getting the passive aggressive 
treatment on this point.
>
> If the netmod WG doesn't have the integrity and strength to fix RFC 
6991 in the BIS version, we should consider changing the OSPF and IS-IS base 
specifications before publication to use inet:ip-address-no-zone.

[as wg-member]

I think we should do the right thing in our (LSR) modules no matter 
what, again, what harm does it do to get it right in the modules under LSR WGs 
direct control?

Actually this is a very bad idea. We don't want to endorse the error in RFC 
6991 that could be fixed in the BIS document. I'm certainly not going to change 
the documents I authored when the world expects an IP address to not include a 
zone. I sent an Email to the RFC 9127 BIS (which is currently in IESG review) 
authors about this issue and apparently they agree with me as they chose not to 
respond.

Just way behind on IETF emails. I can't speak for the other authors but I 
don't agree (too late). But I think we should make the change in 9127-bis. And 
follow current guidelines, as others have mentioned, to tackle what's in 
6991-bis.



That is the I-D that has just been approved by the IESG!

I do wonder about BFD.  Single hop IPv6 would seem to be a case for link 
local even if RFC5881 has a SHOULD NOT for using link local; and IPv6 link 
local is where the zone may be needed to identify the interface. RFC5881 does 
not mention zones.

[Acee]
This is probably better discussed on the BFD list but since single-hop BFD is 
by YANG definition scoped to a single interface, there is no use for zone index 
independent of the usage of link-local addresses. In fact, no one has been able 
to point to an implementation of textual convention usage in product 
configuration. The introduction of zones in RFC 4007 is an interesting but 
unused esoteric feature. The incorporation of zone in the base RFC 6991 IP 
address types and the reluctance to fix it is a travesty.  

Acee
[Acee] 

Tom Petch

Regards,
Reshad.

Thanks,

Acee

The netmod change is a much larger action with a large blast radius 
(not saying it's wrong), and perhaps most importantly is also outside of LSR WG 
control. :)

Thanks,
Chris.
[wg-member]


> Thanks,
> Acee
>
> On 4/5/22, 9:33 AM, "Christian Hopps" 
mailto:cho...@chopps.org>> wrote:
>
>If they are new leaf values why not use the correct no-zone 
variant, what's the harm in doing it right? It has a nice side effect of 
basically restricting the base spec zone values to no-zone only. :)
>
>Thanks,
    >Chris.
>[wg member]
>
>> On Apr 4, 2022, at 12:30, Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
>>
>> In the MIB,  the base types don't include the zone - 
https://www.ietf.org/rfc/rfc4001.txt
>>
>> It was very unfortunate that the YANG IP addresses included the zone 
in the base types.
>>
>> Tom - I think it would be hard to find an author where including the 
zone was a conscious decision.
>>
    >> Thanks,
>> Acee
>>
>> On 4/4/22, 11:55 AM, "tom petch" 
mailto:ie...@btconnect.com>> wrote:
>>
>>  From: Acee Lindem (acee) mailto:a...@cisco.com>>
>>  Sent: 04 April 2022 15:58
>>
>>  Hi Tom, +Juergen, netmod WG,
>>
>>  I think the question you ought to be asking is whether the base 
IPv4 and IPv6 address types should be modified to NOT include the zone and the 
zone versions should be added as a separate YANG type.
>>
>>  The RFC 6991 is under revision now:
>>
>>  https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
>>
>>  However, I'm not sure if the painful backward compatibility 
discussions could be overcome.  We'd also

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Hi Andy,

My opinion remains the same that RFC 4001 got it right with types including the 
zone specification being the exception rather than the default. I know that 
when people think IP address, they think the dotted 4 octet without “%” 
appended. I’d still like to know if there are products that actually make use 
of the zone?

See inline responses in the unsnipped email below.

From: netmod  on behalf of Andy Bierman 

Date: Saturday, April 9, 2022 at 1:38 PM
To: Randy Presuhn 
Cc: "l...@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Sat, Apr 9, 2022 at 9:51 AM Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>> 
wrote:
Hi -

On 2022-04-09 4:36 AM, Christian Hopps wrote:
...
> FWIW, I'm not arguing for this change; however, to be fair, isn't this
> also about the existing published modules that are using the incorrect
> type?

No.  "Incorrect type" is a bit of a mischaracterization.  It's like
saying using "int32" is incorrect if all that is needed is "uint16".
One might say its a little sloppy or mutter "RTFM" under one's breath,
but it's not "incorrect."

You and Martin convinced me the ip-address type cannot be changed.
There are other options.

If a YANG module is using ip-address, and the WG intent was really to
use ip-address-no-zone, then that module can be fixed with an Errata.
The modules should not need to be updated just for this incorrect typedef usage.

The type names are unfortunate but in the future this will not happen again.

Well, these are probably some of the most ubiquitous types in the YANG and 
forcing everyone to use the -no-zone types is more a tragedy than merely 
unfortunate.



Some modules have used a type that potentially can represent more
values than are needed for the intended purpose.  Whether those
implementations will ever accept or produce those values will
depend on whether the code, whether library, generated, or hand-
crafted, enforces the tighter constraints appropriate to the usage
or only the looser constraints appropriate to the type's specification.

But this is also true of every usage of any type where the use
can only exhibit a subset of the possible values of the type,
whether that subsetting is obvious from the description or not,
so I find it really hard to get excited about it.  The more nuanced
a repertoire of types becomes, the more likely developers won't
use exactly the right one, though one would hope that these foibles
are caught during the review process, at least until developers
start reading the documentation for the libraries they employ.

There are many examples where the pattern allows more strings
than the intended usage.  Also, a server can reject any request for any reason.

That does not address the conformance problem that Acee may be concerned about.
What is a server required to support for a leaf with type ip-address?
The text does not look like the zone index is optional for the server to accept.


Even in these cases of "incorrect" usage, as Andy and others
have pointed out, stuff still works, because those cases only
require a subset of the values supported by the type.  If the
proposed change is made, usages requiring the full value space of
the original type definition will break, and those formerly
"incorrect" usages will exhibit no change in their behavior.


It works because clients are not sending addresses with a zone index.
I agree with Martin that the NC/RC server is always obligated to reject a 
request
it cannot fulfill, regardless of the typedef.

I thought Martin said a server not supporting zone could accept the IP address 
and simply ignore the zone? This would seem to be a better options than using 
the -no-zone types.


That is, the proposed change does not improve operation of
anything, and it breaks some things.

yes -- too many years out in the wild this way to switch type names around now.

I know I may be being too pragmatic, but does anyone support zone via %?

Thanks,
Acee


For me, it's more important for stuff to work (and to not break
stuff) than it is to align perfectly with the underlying aesthetics
of some naming system attributed post hoc to a set of types.

Randy

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] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

I hate when people selectively snip my Emails and respond out of context. 
Please don't do that in the future! I'll reply to the more constructive thread. 
Acee

On 4/8/22, 4:45 PM, "Lsr on behalf of Randy Presuhn"  wrote:

Hi -

On 2022-04-08 12:25 PM, Acee Lindem (acee) wrote:
...
> If you look at the existing YANG RFCs rather than drafts that are 
confirming to the error, you'll notice that they don't use the no-zone types:
> 
> https://datatracker.ietf.org/doc/rfc8344/
...

Huh?  RFC 8344 *does* use inet:ipv4-address-no-zone
and inet:ipv6-address-no-zone.

> Also, if you look at the SNMP RFC 4001, you'll note that the base types 
do not include the zone index and RFC8344 references the MIB types using the 
base types (see snippet below).

RFC 4001 addresses the limitation of the IpAddress SMIv2 base type,
which is inherently unsuitable for IPv6 addresses.  The new address
types defined in RFC 4001 have OCTET STRING as their base type. The
"base type" relationship you seem to be inferring reads too
much into the labels, which are merely mnemonic.  One might argue
about the suitability of any particular (non)system of mnemonics,
but the nature of these beasts is that we can't significantly change
them once their published.

> Clearly, it was wrong to make the IP addresses including the zone the 
default

How is it a "default"?  Both zonable and zoneless types are available
to the model developer.  Nothing makes one or the other a default.

> and I'm not sure why there is all this effort not to just admit, fix the 
RFC 6991 BIS version, and be done with it.

30+ years of tradition (and BCP) not permitting types to be changed
after they've been published, I suppose, motivated by our total lack
of control over unpublished usage of these types after their definitions
have been published.

If there were actually something wrong with the semantics or syntax,
I'm sure there would be more sympathy for the argument.  But the heart
of the argument is that the types label's mnemonicity is poor.  That,
coupled with the collateral damage resulting from a "fix", makes
the whole argument terribly unpersuasive to me, particularly
when the definition in question was been published, implemented, and
deployed years ago.

Randy

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

See inline. 

On 4/8/22, 1:59 PM, "netmod on behalf of Randy Presuhn" 
 wrote:

Hi -

On 2022-04-08 5:11 AM, Christian Hopps wrote:
..
> Instead, Acee (I'm not sure I'd call him WG B :) is asserting that 
> *nobody* actually wanted the current type, and it has been misused 
> everywhere and all over. The vast majority of implementations in 
> operation probably can't even handle the actual type (Andy's point). So, 
> Acee is just the messenger of bad news here. Please note that the AD in 
> charge of all this agreed with Acee as well.

That's not the impression one gets from modules like
https://www.ietf.org/archive/id/draft-ietf-mpls-mldp-yang-10.txt
which employs both types.  So, regardless of whether one is willing
to respect YANG's compatibility rules, it's no longer a matter of
speculation whether a name change would cause actual damage -
it clearly would.  Furthermore, my recollection is that the
WG *did* discuss whether the "zonable" property was needed, so
any argument based on the assertion that "*nobody* actually
wanted the current type" seems to me to based on a false premise.

If you look at the existing YANG RFCs rather than drafts that are confirming to 
the error, you'll notice that they don't use the no-zone types:

https://datatracker.ietf.org/doc/rfc8344/
https://datatracker.ietf.org/doc/rfc8349/
https://datatracker.ietf.org/doc/rfc8519/
https://datatracker.ietf.org/doc/rfc9067/

Also, if you look at the SNMP RFC 4001, you'll note that the base types do not 
include the zone index and RFC8344 references the MIB types using the base 
types (see snippet below). Clearly, it was wrong to make the IP addresses 
including the zone the default and I'm not sure why there is all this effort 
not to just admit, fix the RFC 6991 BIS version, and be done with it. 

InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS   current
DESCRIPTION
"Represents an IPv4 network address:
   Octets   Contents Encoding
1-4 IPv4 address network-byte order

 The corresponding InetAddressType value is ipv4(1).

 This textual convention SHOULD NOT be used directly in object
 definitions, as it restricts addresses to a specific format.
 However, if it is used, it MAY be used either on its own or in
 conjunction with InetAddressType, as a pair."
SYNTAX   OCTET STRING (SIZE (4))

InetAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
STATUS   current
DESCRIPTION
"Represents an IPv6 network address:

   Octets   Contents Encoding
1-16IPv6 address network-byte order

 The corresponding InetAddressType value is ipv6(2).

 This textual convention SHOULD NOT be used directly in object
 definitions, as it restricts addresses to a specific format.
 However, if it is used, it MAY be used either on its own or in
 conjunction with InetAddressType, as a pair."
SYNTAX   OCTET STRING (SIZE (16))

InetAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d"
STATUS   current
DESCRIPTION
"Represents a non-global IPv4 network address, together
 with its zone index:

   Octets   Contents Encoding
1-4 IPv4 address network-byte order
5-8 zone index   network-byte order

 The corresponding InetAddressType value is ipv4z(3).

 The zone index (bytes 5-8) is used to disambiguate identical
 address values on nodes that have interfaces attached to
 different zones of the same scope.  The zone index may contain
 the special value 0, which refers to the default zone for each
 scope.

 This textual convention SHOULD NOT be used directly in object
 definitions, as it restricts addresses to a specific format.
 However, if it is used, it MAY be used either on its own or in
 conjunction with InetAddressType, as a pair."
SYNTAX   OCTET STRING (SIZE (8))

InetAddressIPv6z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
STATUS   current
DESCRIPTION
"Represents a non-global IPv6 network address, together
 with its zone index:

   Octets   Contents Encoding
1-16IPv6 address network-byte order
   17-20zone index   network-byte order

 The corresponding InetAddressType value is ipv6z(4).

 The zone index (bytes 17-20) is used to disambiguate
 identical address values on nodes that have interfaces
 attached to different zones of the same scope.  The zone index
 may contain the special value 0, which refers to the default
 zone for each scope.

 This textual convention SHOULD NOT be used directly in 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Jürgen, 

On 4/7/22, 12:08 PM, "Jürgen Schönwälder" 
 wrote:

On Thu, Apr 07, 2022 at 02:35:03PM +0000, Acee Lindem (acee) wrote:
> 
> We already a large number of models that use the existing inet:ip-address 
types whose implementations don't support the zone. Why should we start using 
this esoteric "no-zone" types in new models? Note you have RFC 9127 BIS going 
to through IESG right now... Better to fix it in one place (actually three, 
since there is ipv4-address, ipv6-address, and ip-address) then in who knows 
how many since many vendors import ietf-inet-types in their native models. 
>

I can't tell how many usages of ip-address are out there where the
optional zone never applies and how many usages of ip-address are out
there where dropping the optional zone breaks models for deployments
where link-local addresses are used. What we see may be biased by the
kind of data models we look at, routing related data models may show
different properties than application layer related data models.

Point me to one prevalent implementation that supports the textual convention 
for zone for IPv6 link-local addresses? I suspect this would be akin to Abraham 
finding a righteous man...  

Acee



/js

-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Hi Joel,

On 4/7/22, 1:18 PM, "Joel M. Halpern"  wrote:

Acee, I am missing something basic.
It seems to me that it would be very wrong for the LSR YANG module to 
demand a change to an important type because it turns out that type 
doesn't mean what LSR thought it meant.  Such an error is LSR's problem, 
not the underlying modules.

There seem to be two fixes.  If it is for some reason imperitive to us 
the same typedef we have been using, then put in text / patterns / 
restrictions saying that this model MUST NOT use the scope field.

More reasonably, use a different typedef in this model.

Point me to a usages where the zone is actually desired and supported? 

Acee




Yours,
Joel

On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
> Hi Martin,
> 
> On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:
> 
>  Andy Bierman  wrote:
>  > On Thu, Apr 7, 2022 at 9:11 AM tom petch  
wrote:
>  >
>  > > From: Lsr  on behalf of Rob Wilton 
(rwilton)
>  > > 
>  > > Sent: 07 April 2022 10:25
>  > >
>  > > I basically agree with Acee, and I think that we should do (b):
>  > >
>  > > b) Change the types as suggested and accept that doing 
so breaks
>  > > modules where zone indexes are meaningful.
>  > >
>  > > 
>  > >
>  > > I am concerned that such behaviour will damage the standing of 
the IETF at
>  > > large.
>  > >
>  > >
>  > MAY for the client means MUST for the server.
> 
>  I'm not sure what you mean here.
> 
>  But I'm also not sure I understand what the real problem is.  Just 
b/c
>  the type allows a zone doesn't mean that all leafs that use this type
>  MUST support a zone.  Compare with the value "0.0.0.0".  It is a 
legal
>  value according to the pattern, but it will not be valid in all 
places
>  where this type is used.  And even when an implementation supports
>  zones, it will not accept all legal (according to the pattern) values
>  for the zone index.  Perhaps the solution is to explain this
>  better in the description?
> 
> 
>  > But if no servers actually support it, because the YANG does not 
match
>  > the operational requirements, then is it really a MUST requirement?
>  >
>  > This seems like a bugfix, and the worst thing the IETF could do 
wrt/
>  > standing
>  > is to force the world to change every module that imports the 
typedef.
>  > Since many people were not aware of the full syntax, it is not 
clear that
>  > the WG intent was to include a zone.
> 
>  It is pretty clear IMO that this was not a mistake.  The text
>  explicitly says:
> 
>The IPv4 address may include a zone
>index, separated by a % sign.
> 
>  >
>  > Seems like a bugfix to a pattern, like we have done several times 
already.
> 
>  I don't think this is a bugfix.
> 
> A bugfix for the requirements for the base types that requires fixing the 
pattern and description.
> 
> Acee
> 
> 
>  /martin
> 
> 
>  >
>  > Andy
>  >
>  >
>  >
>  > > We clearly laid down rules as to what updates were regarded as 
compatible
>  > > so that authors of software could be confident that their work 
was robust
>  > > and future-proof.  We did it with SNMP, inter alia, and we have 
carried
>  > > that forward with YANG.  To tear up that understanding , 
creating who knows
>  > > how much disruption, can only harm the standing of IETF.
>  > >
>  > > Much has been said about how implementations have assumed that 
the address
>  > > types do not include a zone but no evidence has been put forward 
for that
>  > > assertion.
>  > >
>  > > I have always assumed that software uses libraries and that the 
libraries
>  > > have been written with an understanding of the specifications 
such that if
>  > > a zone is received over the wire in conformance with the 
specification but
>  > > where the display, field or such like does not allow for a zone, 
then,
>  > &g

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Hi Martin, 

On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Andy Bierman  wrote:
> On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:
> 
> > From: Lsr  on behalf of Rob Wilton (rwilton)
> > 
> > Sent: 07 April 2022 10:25
> >
> > I basically agree with Acee, and I think that we should do (b):
> >
> > b) Change the types as suggested and accept that doing so breaks
> > modules where zone indexes are meaningful.
> >
> > 
> >
> > I am concerned that such behaviour will damage the standing of the IETF 
at
> > large.
> >
> >
> MAY for the client means MUST for the server.

I'm not sure what you mean here.

But I'm also not sure I understand what the real problem is.  Just b/c
the type allows a zone doesn't mean that all leafs that use this type
MUST support a zone.  Compare with the value "0.0.0.0".  It is a legal
value according to the pattern, but it will not be valid in all places
where this type is used.  And even when an implementation supports
zones, it will not accept all legal (according to the pattern) values
for the zone index.  Perhaps the solution is to explain this
better in the description?


> But if no servers actually support it, because the YANG does not match
> the operational requirements, then is it really a MUST requirement?
> 
> This seems like a bugfix, and the worst thing the IETF could do wrt/
> standing
> is to force the world to change every module that imports the typedef.
> Since many people were not aware of the full syntax, it is not clear that
> the WG intent was to include a zone.

It is pretty clear IMO that this was not a mistake.  The text
explicitly says:

  The IPv4 address may include a zone
  index, separated by a % sign.

> 
> Seems like a bugfix to a pattern, like we have done several times already.

I don't think this is a bugfix.

A bugfix for the requirements for the base types that requires fixing the 
pattern and description. 

Acee


/martin


> 
> Andy
> 
> 
> 
> > We clearly laid down rules as to what updates were regarded as 
compatible
> > so that authors of software could be confident that their work was 
robust
> > and future-proof.  We did it with SNMP, inter alia, and we have carried
> > that forward with YANG.  To tear up that understanding , creating who 
knows
> > how much disruption, can only harm the standing of IETF.
> >
> > Much has been said about how implementations have assumed that the 
address
> > types do not include a zone but no evidence has been put forward for 
that
> > assertion.
> >
> > I have always assumed that software uses libraries and that the 
libraries
> > have been written with an understanding of the specifications such that 
if
> > a zone is received over the wire in conformance with the specification 
but
> > where the display, field or such like does not allow for a zone, then,
> > tolerant of what to accept, the zone is silently discarded and the 
address
> > is used without the zone.  But, like the assertion that keeping the zone
> > will cause who knows what damage, I have not done the research to
> > substantiate that assumption.
> >
> > Tom Petch
> >
> > I appreciate that this is an NBC change, but I believe that this is the
> > most intuitive definition and is the best choice longer term.  I also 
note
> > that the base ipv4-address/ipv6-address types in OpenConfig (where they 
use
> > the OC copy/version of inet-types and not ietf-inet-types) don't allow a
> > zone to be specified and assumes the default zone.  They have separate
> > types in cases where a zone is allowed to be specified, i.e., aligned to
> > what (b) proposes.
> >
> > For modules that are using/wanting zones (if any), then they can migrate
> > to the new explicit zone type.   
draft-ietf-netmod-yang-module-versioning,
> > if it keeps its import "revision-or-derived" extension, would also allow
> > such modules to indicate the dependency on the updated 
revision/definition
> > of ietf-inet-types.yang.
> >
> > Of course, the description associated with the updated
> > ietf-inet-types.yang revision should clearly highly the
> > non-backwards-compatible change to the types.
> >
> > Rob
> >
> >
> > -Origi

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Kent, 

On 4/7/22, 4:39 AM, "Kent Watsen"  wrote:


Juergen et. al. ,

> What are our options?
> 
> a) Do nothing and accept that types are called as they are.
> b) Change the types as suggested and accept that doing so breaks
>   modules where zone indexes are meaningful.
> c) Deprecate the types and create a new module defining new types
>   so that modules can opt-in to use better names.
> d) Deprecate the -no-zone types and move back to have a single
>   type for IP addresses.

What’s the value of (d)?  Seems like keeping is better, if only to guide 
readers towards knowing the base types include zones.  And, besides, any 
module-designer wishing to restrict zones would then have to create their own 
“no-zone” types. 


We already a large number of models that use the existing inet:ip-address types 
whose implementations don't support the zone. Why should we start using this 
esoteric "no-zone" types in new models? Note you have RFC 9127 BIS going to 
through IESG right now... Better to fix it in one place (actually three, since 
there is ipv4-address, ipv6-address, and ip-address) then in who knows how many 
since many vendors import ietf-inet-types in their native models. 

Thanks,
Acee

> Any other options?

e) define new types “*-with-zone”
 and deprecate existing “ip*-address” types and recast the “*-no-zone” 
types as derived from the *-with-zone types?  This way it is always a conscious 
decision. 



> How are we going to pick between them?

I don’t think Errata works, since 6991 defining the *-no-zone types makes 
it clear what intended. 


Kent (hatless)




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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Acee Lindem (acee)]

Hey Kent,
Are you behind on your Emails or choosing to ignore the ongoing discussion of 
the ip-address, ipv4-address, and ipv6-address types?
Thanks,
Acee

From: netmod  on behalf of Kent Watsen 

Date: Wednesday, April 6, 2022 at 9:25 PM
To: "draft-ietf-netmod-rfc6991-...@ietf.org" 

Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

This draft has been moved out of the WG.  Now in shepherd write-up.

Comments:
· Section 4 is titled "Internet-Specific Derived Types"
oShould it be something like "Internet Protocol Suite Types"?
· Many places have "Simplified BSD"
oshould be "Revised BSD"


· The "description" for "email-address" says:
o"The canonical format of the domain part of an email-address uses 
lowercase US-ASCII characters.".
§  But I don't see a lowercase-restriction in the pattern.
§  Maybe the description could be clarified?


· Note: `pyang --strict -Werror --canonical 
ietf-inet-ty...@2022-03-22.yang`
o
ietf-inet-ty...@2022-03-22.yang:551: 
error: keyword "length" not in canonical order (see RFC 6020, Section 12)


Kent




On Mar 24, 2022, at 1:17 PM, tom petch 
mailto:ie...@btconnect.com>> wrote:

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
Sent: 22 March 2022 07:11

So we have the following options:

a) Leave revision-date to be defined in ietf-yang-revisions.

b) Define revision-date in ietf-yang-types.

c) Define a date-no-zone type (derived from the date type) which does
  not have the optional time zone offset.



Yes, I like c) for its simplicity and its adequacy

Tom Petch


I am leaning towards option c), having a generic type for a date
without a time zone is the most general type we can provide. If
additional specific revision date semantics are necessary, they can be
provided in ietf-yang-revisions. (Looking at the definition of the
type revision-identifier in RFC 8525, this is really date-no-zone.)

/js

On Tue, Mar 15, 2022 at 08:42:31AM -0700, Andy Bierman wrote:

On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de>
 wrote:


On Mon, Mar 14, 2022 at 05:21:01PM -0700, Andy Bierman wrote:

On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen 
mailto:kent+i...@watsen.net>>
wrote:



All,

1) If you provided WGLC comments on this draft, please review the -12
diff

<
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt> to

ensure that the updates made are good.

2) Juergen notes below that he also removed the "revision-identifier"
typedef, as it is better
defined in the YANG versioning module.  Any objections?

Sorry for the late comment.
I think Juergen listed one option as "rename to revision-date and leave
it

in this module".
I support this option.

There is no chance that the revision date format will be changing any
time

soon.
This is useful for general applications because revision date is widely
used.

The ietf-yang-library module (RFC 8525) currently uses its own
definition of revision-identifier. While this module could adopt a
common definition, the value of such a change is minor.

The question where we place the definition of revision-date is likely
a matter of which role we expect the versioning work to play in the
future. I am relatively neutral on the placement.

Not that important I guess.
One would think the "date" typedef already in the draft would be useful,
but it isn't, and therefore not used.
There is no typedef for the pattern -MM-DD.

/js



Andy




--
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

--
Jürgen Schönwälder  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] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Hi Chris (as WG member),

On 4/5/22, 10:47 AM, "Christian Hopps"  wrote:



> On Apr 5, 2022, at 09:48, Acee Lindem (acee)  wrote:
> 
> [wg-member]
> 
> The thing is that most of the existing RFCs use inet:ip-address rather 
inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address 
in RFC 6991 BIS to not include the zone similar to what was done in the MIB 
(RFC 4001). However, we're getting the passive aggressive treatment on this 
point. 
> 
> If the netmod WG doesn't have the integrity and strength to fix RFC 6991 
in the BIS version, we should consider changing the OSPF and IS-IS base 
specifications before publication to use inet:ip-address-no-zone. 

[as wg-member]

I think we should do the right thing in our (LSR) modules no matter what, 
again, what harm does it do to get it right in the modules under LSR WGs direct 
control?

Actually this is a very bad idea. We don't want to endorse the error in RFC 
6991 that could be fixed in the BIS document. I'm certainly not going to change 
the documents I authored when the world expects an IP address to not include a 
zone. I sent an Email to the RFC 9127 BIS (which is currently in IESG review) 
authors about this issue and apparently they agree with me as they chose not to 
respond. 

Thanks,
Acee

The netmod change is a much larger action with a large blast radius (not 
saying it's wrong), and perhaps most importantly is also outside of LSR WG 
control. :)

Thanks,
Chris.
[wg-member]


> Thanks,
> Acee 
> 
> On 4/5/22, 9:33 AM, "Christian Hopps"  wrote:
> 
>If they are new leaf values why not use the correct no-zone variant, 
what's the harm in doing it right? It has a nice side effect of basically 
restricting the base spec zone values to no-zone only. :)
> 
>Thanks,
>Chris.
>    [wg member]
> 
>> On Apr 4, 2022, at 12:30, Acee Lindem (acee) 
 wrote:
>> 
>> In the MIB,  the base types don't include the zone - 
https://www.ietf.org/rfc/rfc4001.txt
>> 
>> It was very unfortunate that the YANG IP addresses included the zone in 
the base types. 
>> 
>> Tom - I think it would be hard to find an author where including the 
zone was a conscious decision. 
    >> 
    >> Thanks,
>> Acee
>> 
>> On 4/4/22, 11:55 AM, "tom petch"  wrote:
>> 
>>   From: Acee Lindem (acee) 
>>   Sent: 04 April 2022 15:58
>> 
>>   Hi Tom, +Juergen, netmod WG,
>> 
>>   I think the question you ought to be asking is whether the base IPv4 
and IPv6 address types should be modified to NOT include the zone and the zone 
versions should be added as a separate YANG type.
>> 
>>   The RFC 6991 is under revision now:
>> 
>>   https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
>> 
>>   However, I'm not sure if the painful backward compatibility 
discussions could be overcome.  We'd also have to admit that it was a big 
mistake to include the zone in the base addresses. In any case, I don't think 
we just start using the no-zone types when the base addresses types are used 
everywhere.
>> 
>>   
>> 
>>   Well, there are plenty of uses of the no-zone types as well, so some 
authors, some YANG doctors, have made the conscious choice to use them.  I 
cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and 
there are others.
>> 
>>   Also, some authors want the zone information as part of their leaf.
>> 
>>   Tom Petch
>> 
>>   Thanks,
>>   Acee
>> 
>> 
>> 
>>   On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch"  wrote:
>> 
>>   I assume that this is a refresh while waiting for ospf.yang to 
wind its way through the system
>> 
>>   I wonder if the ip address should be the no-zone variant from 
RFC6991 - I never know the answer to that so keep asking.
>> 
>>   Some time the contact needs updating to https://datatracker and 
the TLP to 'Revised'
>> 
>>   Tom Petch
>> 
>>   
>>   From: Lsr  on behalf of 
internet-dra...@ietf.org 
>>   Sent: 07 March 2022 03:14
>>   To: i-d-annou...@ietf.org
>>   Cc: l...@ietf.org
>>   Subject: [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>> 
>> 
>>   A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
>

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Jürgen and netmod WG,  +IESG,

It is not just the IETF models that are using the inet:ip-address for the 
standard IPv4/IPv6 addresses without zones. Every vendor’s native models and 
the OpenConfig models use the base types and expect the standard IP address 
notation. If we don’t fix this, it is something that people can point to as 
another example of the IETF being out of touch with reality.

I thought about more, and it might make the backward compatibility easier if we 
just leave the existing ip-address-no-zone, ipv4-address-no-zone, and 
ipv6-address-no-zone types and add *-zone types for the remote possibility that 
someone actually wants to include the zone.  In the existing RFC 6991 BIS 
document, we could merely remove the zone from the ip-address, ipv4-address, 
and ipv6-address types and classify this as we would any other bug fix. While 
including the zone was the original intent of the base types, this is what 
those of us who work on software products would classify as a requirements bug.

Thanks,
Acee

From: Andy Bierman 
Date: Tuesday, April 5, 2022 at 3:21 PM
To: Juergen Schoenwaelder , Andy Bierman 
, Acee Lindem , "l...@ietf.org" 
, "netmod@ietf.org" 
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt



On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote:
> >
> > The best outcome would be to fix ip-address to not include the zone,
> > introduce ip-address-zone, and deprecate ip-address-no-zone. My take all
> > the is that all the existing usages do not require zone and this would be a
> > fix as opposed to a change.
> >
> >
> I don't think this will harm our implementations.
> The type is still string. The pattern will change but that is handled by a
> library.
> Whatever pattern is used will get handled the same way.

Either a zone is allowed to be present or it is not, this does make a
difference, its not a cosmetic change.


True. The code will probably accept the pattern then fail trying to use the 
string.
If the client sends the form with a zone.




> The same problem exists for 'date' and 'date-no-zone' types,
> but they are not used very much.

Perhaps we should call types a, b, c, and so on - this may force
people to read the descriptions. ;-)

For some reason, the smarter the person, the less likely they are to
read any of the documentation before using some software.
I call it the "it should work the way I would design it" phenomenon :-)

You have to admit that Acee's suggestion is more intuitive than the current
definitions.

Clearly an NBC change.
IMO it is more useful to put some YANG extension magic in these specific 
typedefs
than just bumping a major revision number. This is a great use-case for the 
version DT.

There probably is no solution path where nobody has to change any YANG or any 
code
and everything still works.



/js

Andy

--
Jürgen Schönwälder  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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" 
 wrote:

On Tue, Apr 05, 2022 at 01:48:25PM +0000, Acee Lindem (acee) wrote:
> [wg-member]
> 
> The thing is that most of the existing RFCs use inet:ip-address rather 
inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address 
in RFC 6991 BIS to not include the zone similar to what was done in the MIB 
(RFC 4001). However, we're getting the passive aggressive treatment on this 
point. 
> 

You either assume that all existing uses of inet:ip-address (inside
the IETF and outside the IETF) are wrong or you are willing to break
all the existing correct uses of inet:ip-address so that the type
matches your expectations.

The existing YANG update rules are pretty clear that changing the
semantics of definitions is not allowed. Hence, all the WG could do
is to deprecate ip-address and to introduce ip-address-zone.

The best outcome would be to fix ip-address to not include the zone, introduce 
ip-address-zone, and deprecate ip-address-no-zone. My take all the is that all 
the existing usages do not require zone and this would be a fix as opposed to a 
change. 

Acee

/js

-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

[wg-member]

The thing is that most of the existing RFCs use inet:ip-address rather 
inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address 
in RFC 6991 BIS to not include the zone similar to what was done in the MIB 
(RFC 4001). However, we're getting the passive aggressive treatment on this 
point. 

If the netmod WG doesn't have the integrity and strength to fix RFC 6991 in the 
BIS version, we should consider changing the OSPF and IS-IS base specifications 
before publication to use inet:ip-address-no-zone. 

Thanks,
Acee 

On 4/5/22, 9:33 AM, "Christian Hopps"  wrote:

If they are new leaf values why not use the correct no-zone variant, what's 
the harm in doing it right? It has a nice side effect of basically restricting 
the base spec zone values to no-zone only. :)

Thanks,
Chris.
[wg member]

> On Apr 4, 2022, at 12:30, Acee Lindem (acee) 
 wrote:
> 
> In the MIB,  the base types don't include the zone - 
https://www.ietf.org/rfc/rfc4001.txt
> 
> It was very unfortunate that the YANG IP addresses included the zone in 
the base types. 
> 
> Tom - I think it would be hard to find an author where including the zone 
was a conscious decision. 
> 
> Thanks,
> Acee
> 
> On 4/4/22, 11:55 AM, "tom petch"  wrote:
> 
>From: Acee Lindem (acee) 
>Sent: 04 April 2022 15:58
> 
>Hi Tom, +Juergen, netmod WG,
> 
>I think the question you ought to be asking is whether the base IPv4 
and IPv6 address types should be modified to NOT include the zone and the zone 
versions should be added as a separate YANG type.
> 
>The RFC 6991 is under revision now:
> 
>https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
> 
>However, I'm not sure if the painful backward compatibility 
discussions could be overcome.  We'd also have to admit that it was a big 
mistake to include the zone in the base addresses. In any case, I don't think 
we just start using the no-zone types when the base addresses types are used 
everywhere.
> 
>
> 
>Well, there are plenty of uses of the no-zone types as well, so some 
authors, some YANG doctors, have made the conscious choice to use them.  I 
cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and 
there are others.
> 
>Also, some authors want the zone information as part of their leaf.
> 
>Tom Petch
> 
>Thanks,
>Acee
> 
> 
> 
>On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch"  wrote:
> 
>I assume that this is a refresh while waiting for ospf.yang to 
wind its way through the system
> 
>I wonder if the ip address should be the no-zone variant from 
RFC6991 - I never know the answer to that so keep asking.
> 
>Some time the contact needs updating to https://datatracker and 
the TLP to 'Revised'
> 
>Tom Petch
> 
>
>From: Lsr  on behalf of 
internet-dra...@ietf.org 
>Sent: 07 March 2022 03:14
>To: i-d-annou...@ietf.org
>Cc: l...@ietf.org
>Subject: [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> 
> 
>A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
>This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : YANG Model for OSPFv3 Extended LSAs
>Authors : Acee Lindem
>  Sharmila Palani
>  Yingzhen Qu
>Filename: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>Pages   : 29
>Date: 2022-03-06
> 
>Abstract:
>   This document defines a YANG data model augmenting the IETF 
OSPF YANG
>   model to provide support for OSPFv3 Link State Advertisement 
(LSA)
>   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs 
provide
>   extensible TLV-based LSAs for the base LSA types defined in RFC 
5340.
> 
> 
>The IETF datatracker status page for this draft is:
>
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
>There is also an htmlized version available at:
>
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

In the MIB,  the base types don't include the zone - 
https://www.ietf.org/rfc/rfc4001.txt

It was very unfortunate that the YANG IP addresses included the zone in the 
base types. 

Tom - I think it would be hard to find an author where including the zone was a 
conscious decision. 

Thanks,
Acee

On 4/4/22, 11:55 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 04 April 2022 15:58

Hi Tom, +Juergen, netmod WG,

I think the question you ought to be asking is whether the base IPv4 and 
IPv6 address types should be modified to NOT include the zone and the zone 
versions should be added as a separate YANG type.

The RFC 6991 is under revision now:

https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/

However, I'm not sure if the painful backward compatibility discussions 
could be overcome.  We'd also have to admit that it was a big mistake to 
include the zone in the base addresses. In any case, I don't think we just 
start using the no-zone types when the base addresses types are used everywhere.



Well, there are plenty of uses of the no-zone types as well, so some 
authors, some YANG doctors, have made the conscious choice to use them.  I 
cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and 
there are others.

Also, some authors want the zone information as part of their leaf.

Tom Petch

Thanks,
Acee



On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch"  wrote:

I assume that this is a refresh while waiting for ospf.yang to wind its 
way through the system

I wonder if the ip address should be the no-zone variant from RFC6991 - 
I never know the answer to that so keep asking.

Some time the contact needs updating to https://datatracker and the TLP 
to 'Revised'

Tom Petch


From: Lsr  on behalf of internet-dra...@ietf.org 

Sent: 07 March 2022 03:14
To: i-d-annou...@ietf.org
Cc: l...@ietf.org
Subject: [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
Pages   : 29
Date: 2022-03-06

Abstract:
   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.


The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10


Internet-Drafts are also available by rsync at 
rsync.ietf.org::internet-drafts


___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Acee Lindem (acee)]

Hi Tom, +Juergen, netmod WG,  

I think the question you ought to be asking is whether the base IPv4 and IPv6 
address types should be modified to NOT include the zone and the zone versions 
should be added as a separate YANG type. 

The RFC 6991 is under revision now:

https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/

However, I'm not sure if the painful backward compatibility discussions could 
be overcome.  We'd also have to admit that it was a big mistake to include the 
zone in the base addresses. In any case, I don't think we just start using the 
no-zone types when the base addresses types are used everywhere. 

Thanks,
Acee



On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch"  wrote:

I assume that this is a refresh while waiting for ospf.yang to wind its way 
through the system

I wonder if the ip address should be the no-zone variant from RFC6991 - I 
never know the answer to that so keep asking.

Some time the contact needs updating to https://datatracker and the TLP to 
'Revised'

Tom Petch


From: Lsr  on behalf of internet-dra...@ietf.org 

Sent: 07 March 2022 03:14
To: i-d-annou...@ietf.org
Cc: l...@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
Pages   : 29
Date: 2022-03-06

Abstract:
   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10


Internet-Drafts are also available by rsync at 
rsync.ietf.org::internet-drafts


___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

Re: [netmod] [babel] NULL value for uint16

[Acee Lindem (acee)]

All,

From: netmod  on behalf of Mahesh Jethanandani 

Date: Tuesday, September 14, 2021 at 1:38 PM
To: Juergen Schoenwaelder 
Cc: Babel at IETF , "STARK, BARBARA H" , 
"netmod@ietf.org" 
Subject: Re: [netmod] [babel] NULL value for uint16

Hi Juergen,


On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:


As I mentioned, BBF TR-181 uses int with range -1:65535 with -1 meaning NULL. 
So I certainly have no issue with that approach. The language in RFC9046 was 
intended to make sure this approach was allowed, since this is how it's done in 
TR-181.
I guess I am a bit surprised to learn that YANG doesn't seem to have a 
preferred way to handle this. Unfortunately, given my considerable lack of YANG 
expertise, I can't recommend the "right" way to model this in YANG. I can only 
insist that the model be able to express a value in the range 0 to 2^16 and 
NULL value for these parameters.
Independent of the fact that the words in RFC9046 don't seem to have expressed 
this perfectly clearly, that is absolutely the intent of those words. I 
apologize that the RFC9046 words don't seem to be sufficiently clear.

Since you do mention the possibility of using -1 for NULL, I'd like to 
understand who might find this approach unacceptable? The language in the 
information model was definitely intended to express the acceptability of using 
this approach from a Babel WG perspective (because I knew that's how it would 
be done in TR-181). Would this be unacceptable to people with YANG expertise? I 
think my preference would be to use this approach, since it would provide 
additional consistency between the TR-181 and YANG models.

If other data models use an extended integer range and -1 to indicate
a special case, then this may be a strong reason to do the same in the
IETF YANG data model. Consistency across data models is a value, in
particular for systems that may have to support multiple. While the
conversion of different notations no hard, its one more thing to
potentially get wrong.

If you were starting with a blank sheet of paper, then the YANG idiom
would likely be to use a union of a 16-bit integer and a special
(string) value, which might even be of type empty.

I hear two suggestions on what the “other” construct should be in the union 
statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any 
pros/cons for either of the approaches?

“type empty” is cleaner than a boolean indicating whether or not a value is 
specified. In fact, it wouldn’t make sense to for a boolean to be in a union 
with the specified value.

Acee



One of the reasons to have no common approach to these kind of
questions is to provide the flexibility needed to do the right thing
in different contexts. Of course, you may want to stay consistent in a
data model or a collection of related data model.

I skimmed RFC 8407 and it seems we do not have text discussion this
specific situation. Perhaps we should have text, perhaps I have
overlooked it. ;-) I think there are different patterns to choose from
to handle this situation with their various pros and cons.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] Typedefs for bandwidth

[Acee Lindem (acee)]

I'd be all for using some unsigned integer quantity. I think it was a mistake 
for using IEEE floating point in the first place. This floating point nonsense 
was carried over to Traffic Engineering (TE) from early work done on transport 
area on RSVP. For example, https://www.rfc-editor.org/rfc/rfc2210.txt and we've 
been stuck with it ever since... 

Thanks,
Acee

On 5/14/21, 6:08 AM, "netmod on behalf of Italo Busi"  wrote:

Reshad, Juergen,

Actually, there is some on-going discussion within TEAS because some packet 
technology-specific YANG modules are not using the bandwidth-ieee-float32 but 
prefers using some uint type:

https://github.com/tsaad-dev/te/issues/116

The ietf-te-packet-types already defines bandwidth-kbps, bandwidth-mbps and 
bandwidth-gbps but during the discussion of this open issue it was pointed out 
that it would be desirable to specify both the bandwidth and the units 
(Kbps/Mbps/Gbps)

Italo

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: giovedì 13 maggio 2021 19:25
> To: Reshad Rahman 
> Cc: 'netmod@ietf.org' 
> Subject: Re: [netmod] Typedefs for bandwidth
> 
> On Thu, May 13, 2021 at 11:57:26AM -0400, Reshad Rahman wrote:
> > Hi,
> >
> >
> >
> > Has there been any discussions wrt adding new  bandwidth types e.g. the
> bandwidth-xxx types in draft-ietf-teas-yang-te-types? I see RFC8294 has
> bandwidth-ieee-float32 but it doesn’t have units (Kbps/Mbps/Gbps).
> >
> 
> The description of bandwidth-ieee-float32 says:
> 
>   The units are octets per second.
> 
> Note that draft-ietf-teas-yang-te-types has been published as RFC 8776 in 
June
> 2020, it should be safe to use these definitions.
> 
> /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] YANG questions

[Acee Lindem (acee)]

Hi Tony,

I would argue that YANG is a data modeling language. Another disadvantage of 
the bits type that it isn't augmentable with new bits. Hence, usage of unused 
bits requires a new version of the module as opposed to an augmentation. For 
that reason, we greatly limited their usage in routing modules and used 
identities instead. 

Thanks,
Acee

On 4/2/21, 12:14 PM, "netmod on behalf of Tony Li"  wrote:


Hi Lada,

Thanks for your reply.  At heart, I guess I’m asking a more fundamental 
question: is YANG intended as a data modelling language or as a data structure 
modelling language?

Your reply suggests the former: structure is irrelevant to YANG.  If that’s 
true, then what’s the point in ‘position’?  And why do you need ‘bits’ when you 
have ‘binary’?

Confused,
Tony


> On Apr 2, 2021, at 1:27 AM, Ladislav Lhotka  
wrote:
> 
> Tony Li  writes:
> 
>> Hi,
>> 
>> I have some basic questions about YANG. I’m pretty certain this is NOT 
the right place to ask them, so please feel free to redirect me.
>> 
>> 
>> 1) Is there a way to define the width of an enumeration?  Suppose I had 
an enumeration that was in a 16 bit field, how do I describe that?
> 
> In the description, if necessary. However, this should be an 
implementation detail, as long as the underlying numeric type can accommodate 
all enums.
> 
> You could perhaps also define and enum for the highest possible value and 
make in reserved.
> 
>> 
>> 2) How do I model a non-octet sized multi-bit field?  For example, if 
there is a 5 bit numeric value as part of some ‘bits’?  Position only takes a 
single value, I can’t really say ‘position 3-7’.
> 
> In this case, I would question whether the 'bits' type is really 
appropriate. It might be useful to split the value into multiple items in YANG.
> 
> Lada
> 
>> 
>> Thanks,
>> Tony
>> ___
>> 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] [mpls] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tarek,
Can you also add the description of the native MPLS RIB to the text? 
Thanks,
Acee

On 8/14/20, 12:27 PM, "mpls on behalf of Acee Lindem (acee)" 
 wrote:

Hi Tarek,
This works for me. 
Thanks,
Acee

On 8/14/20, 12:25 PM, "Tarek Saad"  wrote:

Hi Acee and Tom,

The authors of ID: draft-ietf-mpls-base-yang met and we discussed the 
points below.
We understand that RFC8349 defines an AF-agnostic model for RIBs. 
RFC8349 defined only two types of RIBs (IPv4 and IPv6 RIBs), but we envision 
other types of RIBs too (e.g. L2 RIB, MCAST RIB, etc.), in addition to MPLS RIB 
-- and we hope all such RIBs indeed leverage the generic RIB model introduced 
in RFC8349.

We revisited Acee's suggestion and made a small modification (on top of 
it) that makes IP routes, MPLS routes (and possibly L2 or MCAST routes in 
future) - all have similar MPLS augmentation (in terms of local-label) while 
still adhering with RFC8349 to augment with leaf destination-prefix.

augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
  when "derived-from-or-self(../../rt:address-family, "
 + "'mpls:mpls')" {
description
  "This augment is valid only for native MPLS routes.";
  }
  description
"This leaf augments a native MPLS route.";
  leaf destination-prefix {
type leafref {
  path "../local-label";
}
description
  "MPLS destination prefix.";
  }
}

We follow same approach for the active route RPC and continue to use a 
leaf "destination-address" as input (that points to a local-label leaf).
If this is acceptable, we believe the errata 6251 can be rejected and 
we'll proceed with the change in the MPLS RIB model.

Regards,
Tarek (for authors)

On 8/11/20, 9:08 AM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


Hi Tom, Draft Authors,

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for 
non-IP MPLS routes. Given that the draft wasn't modeled correctly, this wasn't 
apparent to most of the reviewers.
  2. Add an MPLS AF only augmentation (enforced via a when 
statement) to each route for the MPLS AF specific destination-prefix or 
destination-address.
  3. Limit the current local-label augmentation to non-MPLS AFs.
  4. Limit the active-route augmentation to AF MPLS and change the 
input to destination-address.

    Thanks,
    Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other 
problems with this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) 
RIB to return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the 
MPLS RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting 
the leaf name that identifies an entry in RIB to "destination-address" only - 
in MPLS RIB the entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC 
augmentation must have a when statement restricting it to AF MPLS. Also, 
local-label is a leaf which is applicable to all address families. It cannot be 
the AF MPLS destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised 
the issue of why the 'MUST' in the description in RFC8349 was not enforced in 
the YANG and 5may20 Martin explained that there is a rule in the YANG ABNF of 
input-stmt that makes the obvious impossible:-(  You are raising more profound 
issues about the RIB that I had not perceived when I reviewed mpls-base-yang 
for which I, and I hope everyone else, will be grateful.

If this mpls I-D

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tarek,
This works for me. 
Thanks,
Acee

On 8/14/20, 12:25 PM, "Tarek Saad"  wrote:

Hi Acee and Tom,

The authors of ID: draft-ietf-mpls-base-yang met and we discussed the 
points below.
We understand that RFC8349 defines an AF-agnostic model for RIBs. RFC8349 
defined only two types of RIBs (IPv4 and IPv6 RIBs), but we envision other 
types of RIBs too (e.g. L2 RIB, MCAST RIB, etc.), in addition to MPLS RIB -- 
and we hope all such RIBs indeed leverage the generic RIB model introduced in 
RFC8349.

We revisited Acee's suggestion and made a small modification (on top of it) 
that makes IP routes, MPLS routes (and possibly L2 or MCAST routes in future) - 
all have similar MPLS augmentation (in terms of local-label) while still 
adhering with RFC8349 to augment with leaf destination-prefix.

augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
  when "derived-from-or-self(../../rt:address-family, "
 + "'mpls:mpls')" {
description
  "This augment is valid only for native MPLS routes.";
  }
  description
"This leaf augments a native MPLS route.";
  leaf destination-prefix {
type leafref {
  path "../local-label";
}
description
  "MPLS destination prefix.";
  }
}

We follow same approach for the active route RPC and continue to use a leaf 
"destination-address" as input (that points to a local-label leaf).
If this is acceptable, we believe the errata 6251 can be rejected and we'll 
proceed with the change in the MPLS RIB model.

Regards,
Tarek (for authors)

On 8/11/20, 9:08 AM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


Hi Tom, Draft Authors,

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for 
non-IP MPLS routes. Given that the draft wasn't modeled correctly, this wasn't 
apparent to most of the reviewers.
  2. Add an MPLS AF only augmentation (enforced via a when statement) 
to each route for the MPLS AF specific destination-prefix or 
destination-address.
  3. Limit the current local-label augmentation to non-MPLS AFs.
  4. Limit the active-route augmentation to AF MPLS and change the 
input to destination-address.

    Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other problems 
with this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB 
to return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the 
MPLS RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the 
leaf name that identifies an entry in RIB to "destination-address" only - in 
MPLS RIB the entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation 
must have a when statement restricting it to AF MPLS. Also, local-label is a 
leaf which is applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised the 
issue of why the 'MUST' in the description in RFC8349 was not enforced in the 
YANG and 5may20 Martin explained that there is a rule in the YANG ABNF of 
input-stmt that makes the obvious impossible:-(  You are raising more profound 
issues about the RIB that I had not perceived when I reviewed mpls-base-yang 
for which I, and I hope everyone else, will be grateful.

If this mpls I-D is to proceed in the immediate future, it looks 
like the action may have to be deferred for future study.

More generally, I think that the interaction of forward by address 
and forward by label is challenging.  When first I looked at the MPLS I-D I was 
surprised at the way RFC8349 was augmented.  I had not seen MPLS as an 
alternative to IPv4 or IPv6 or ... in the way in which the RFC is used

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tom, 

On 8/15/20, 8:25 AM, "tom petch"  wrote:

From: Tarek Saad 
Sent: 14 August 2020 17:24

Hi Acee and Tom,

The authors of ID: draft-ietf-mpls-base-yang met and we discussed the 
points below.
We understand that RFC8349 defines an AF-agnostic model for RIBs. RFC8349 
defined only two types of RIBs (IPv4 and IPv6 RIBs), but we envision other 
types of RIBs too (e.g. L2 RIB, MCAST RIB, etc.), in addition to MPLS RIB -- 
and we hope all such RIBs indeed leverage the generic RIB model introduced in 
RFC8349.

We revisited Acee's suggestion and made a small modification (on top of it) 
that makes IP routes, MPLS routes (and possibly L2 or MCAST routes in future) - 
all have similar MPLS augmentation (in terms of local-label) while still 
adhering with RFC8349 to augment with leaf destination-prefix.

augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
  when "derived-from-or-self(../../rt:address-family, "
 + "'mpls:mpls')" {
description
  "This augment is valid only for native MPLS routes.";
  }
  description
"This leaf augments a native MPLS route.";
  leaf destination-prefix {
type leafref {
  path "../local-label";
}
description
  "MPLS destination prefix.";
  }
}

We follow same approach for the active route RPC and continue to use a leaf 
"destination-address" as input (that points to a local-label leaf).
If this is acceptable, we believe the errata 6251 can be rejected and we'll 
proceed with the change in the MPLS RIB model.


Tarek

Looks good but what about the other augments?  In RFC8349, the AF 
constraint is applied to augments to route, simple next hop and next hop list.  
You say that you will add the constraint to the route in so doing creating an 
MPLS RIB but what about next hop?


These are needed for the AF IPv4/IPv6 RIBs for routes with MPLS paths as you 
would see in vendor implementations. It was the MPLS RIB that was the source of 
confusion as the local-label leaf was an optional attribute for AF IPv4/IPv6 
RIB sbut the primary RIB key for AF MPLS. Hopefully the MPLS-specific 
destination-prefix leaf will make this more obvious. 

Thanks,
Acee

    Tom Petch

Regards,
Tarek (for authors)

On 8/11/20, 9:08 AM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


Hi Tom, Draft Authors,

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for 
non-IP MPLS routes. Given that the draft wasn't modeled correctly, this wasn't 
apparent to most of the reviewers.
  2. Add an MPLS AF only augmentation (enforced via a when statement) 
to each route for the MPLS AF specific destination-prefix or 
destination-address.
  3. Limit the current local-label augmentation to non-MPLS AFs.
  4. Limit the active-route augmentation to AF MPLS and change the 
input to destination-address.

    Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other problems 
with this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB 
to return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the 
MPLS RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the 
leaf name that identifies an entry in RIB to "destination-address" only - in 
MPLS RIB the entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation 
must have a when statement restricting it to AF MPLS. Also, local-label is a 
leaf which is applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised the 
issue of why the 'MUST' in the description in RFC8349 was not enforced in the 
YANG and 5may20 Martin explained that

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tom, 
The problem is that RFC 8349 defines an AF-agnostic model for a RIB. The draft 
augments the base model with optional MPLS attributes that would ostensibly be 
applicable to all AFs. What most people miss, is that it also hijacks the base 
model for the MPLS address-family and subverts the AF-agnostic model. This 
shouldn't and can't be fixed with an Errata for RFC 8349.
Thanks,
Acee
On 8/14/20, 7:45 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 14:08

Hi Tom, Draft Authors,

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for non-IP 
MPLS routes. Given that the draft wasn't modeled correctly, this wasn't 
apparent to most of the reviewers.
  2. Add an MPLS AF only augmentation (enforced via a when statement) to 
each route for the MPLS AF specific destination-prefix or destination-address.
  3. Limit the current local-label augmentation to non-MPLS AFs.
  4. Limit the active-route augmentation to AF MPLS and change the input to 
destination-address.


'easily'  mmm... I have been getting my mind around this and see what Acee 
means and agree.  The I-D specifies an MPLS address family but then does not 
create the RIB entries for it in the way that e.g. IPv4 unicast does in  
RFC8349.  Easy may be but quite a change  Another option, again a significant 
change, would be to cater only for IP address family with MPLS and drop the 
MPLS address family.  Either way, whatever the authors decide, I cannot 
personally see this falling within the scope or an Erratum or for the IETF Last 
Call to complete in a week's time.

I have dropped the RFC Editor and netconf-chairs pro tem

Tom Petch

Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

    From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other problems with 
this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to 
return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS 
RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf 
name that identifies an entry in RIB to "destination-address" only - in MPLS 
RIB the entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation must 
have a when statement restricting it to AF MPLS. Also, local-label is a leaf 
which is applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised the 
issue of why the 'MUST' in the description in RFC8349 was not enforced in the 
YANG and 5may20 Martin explained that there is a rule in the YANG ABNF of 
input-stmt that makes the obvious impossible:-(  You are raising more profound 
issues about the RIB that I had not perceived when I reviewed mpls-base-yang 
for which I, and I hope everyone else, will be grateful.

If this mpls I-D is to proceed in the immediate future, it looks like 
the action may have to be deferred for future study.

More generally, I think that the interaction of forward by address and 
forward by label is challenging.  When first I looked at the MPLS I-D I was 
surprised at the way RFC8349 was augmented.  I had not seen MPLS as an 
alternative to IPv4 or IPv6 or ... in the way in which the RFC is used although 
the RFC does state that it can be; rather, to me, labels are a different 
animal, but I assumed that everyone knew what they were doing.

Tom Petch


Thanks,
Acee



There should be a 'when' check to enforce the 'MUST' but the rules 
of YANG do not allow it in this structure.  I raised this on the NETMOD list at 
the time of WGLC and Martin pointed me to a rule in the ABNF which prohibits 
such a check.  He also said that the rule was not needed and would be a 
candidate to remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a 
constraint that must be enforced in the YANG

Tom Petch
&

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tarek,

On 8/11/20, 1:36 PM, "Tarek Saad"  wrote:

Hi Acee and Tom,

Thanks for your feedback and suggestions. Please see further response 
inline..

On 8/11/20, 9:08 AM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


Hi Tom, Draft Authors,

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for 
non-IP MPLS routes. Given that the draft wasn't modeled correctly, this wasn't 
apparent to most of the reviewers.
[TS]: sure, we can add more text to this section. However,
  2. Add an MPLS AF only augmentation (enforced via a when statement) 
to each route for the MPLS AF specific destination-prefix or 
destination-address.
  3. Limit the current local-label augmentation to non-MPLS AFs.
[TS]: you are asking to overload "destination-prefix" to carry the MPLS 
label for the MPLS RIB only 

The AF specific type for the destination-prefix would be rt-types:mpls-label. 
RFC 8349 was designed to support AF agnostic RIBs and if you are going to 
augment it, you have to fix into the framework. If you don't, you don't, you 
should add a separate table for MPLS. It seems a bit strange to consider raw 
MPLS its own AF when it isn't considered an AF in other IETF documents.  

Thanks,
Acee




-  and to continue to use local-label to carry the label for IP RIBs - this is 
a bit awkward. To illustrate:

Currently, ID:draft-ietf-mpls-base-yang models as:
=
IP RIB route:
Route {
   Destination-prefix = 192.168.0.0/24
   Next-hop-address = 10.0.0.2
   Local-label = 16000 (draft-ietf-mpls-base-yang adds this as augmentation)
}
MPLS RIB route:
Route {
   Local-label = 18000
   Next-hop-address = 10.0.0.2
}

Acee is suggesting:
===
IP RIB route (same as in ID:draft-ietf-mpls-base-yang)
Route {
   Destination-prefix = 192.168.0.0/24
   Next-hop-address = 10.0.0.2
   Local-label = 16000
}
MPLS RIB route:
Route {
   Destination-prefix = 18000
   Next-hop-address = 10.0.0.2
}
IMO, it is awkward that MPLS label is carried in local-label for IP RIBs 
routes, while it is carried in destination-prefix for MPLS AF routes.

  4. Limit the active-route augmentation to AF MPLS and change the 
input to destination-address.
[TS]: I'm summarizing intention of ID:draft-ietf-mpls-base-yang in the 
example below to illustrate:
1) RFC 8349 defines RPC (equivalent to "show route 192.168.0.1":
Input:
  destination-address (IP=192.168.0.1, RIB AF=IPv4)
Output:
  Active-route

2) ID:draft-ietf-mpls-base-yang wants to reuse this RPC (equivalent to 
"show route mpls-label 16000")
Input:
   Local-label (label=18000, RIB AF=MPLS)
Output:
  Active-route

Regards,
Tarek

Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other problems 
with this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB 
to return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the 
MPLS RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the 
leaf name that identifies an entry in RIB to "destination-address" only - in 
MPLS RIB the entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation 
must have a when statement restricting it to AF MPLS. Also, local-label is a 
leaf which is applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised the 
issue of why the 'MUST' in the description in RFC8349 was not enforced in the 
YANG and 5may20 Martin explained that there is a rule in the YANG ABNF of 
input-stmt that makes the obvious impossible:-(  You are raising more profound 
issues about 

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tom, Draft Authors, 

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for non-IP MPLS 
routes. Given that the draft wasn't modeled correctly, this wasn't apparent to 
most of the reviewers. 
  2. Add an MPLS AF only augmentation (enforced via a when statement) to each 
route for the MPLS AF specific destination-prefix or destination-address. 
  3. Limit the current local-label augmentation to non-MPLS AFs. 
  4. Limit the active-route augmentation to AF MPLS and change the input to 
destination-address. 

Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other problems with 
this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to 
return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to 
return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name 
that identifies an entry in RIB to "destination-address" only - in MPLS RIB the 
entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation must have 
a when statement restricting it to AF MPLS. Also, local-label is a leaf which 
is applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised the issue 
of why the 'MUST' in the description in RFC8349 was not enforced in the YANG 
and 5may20 Martin explained that there is a rule in the YANG ABNF of input-stmt 
that makes the obvious impossible:-(  You are raising more profound issues 
about the RIB that I had not perceived when I reviewed mpls-base-yang for which 
I, and I hope everyone else, will be grateful.

If this mpls I-D is to proceed in the immediate future, it looks like the 
action may have to be deferred for future study.

More generally, I think that the interaction of forward by address and 
forward by label is challenging.  When first I looked at the MPLS I-D I was 
surprised at the way RFC8349 was augmented.  I had not seen MPLS as an 
alternative to IPv4 or IPv6 or ... in the way in which the RFC is used although 
the RFC does state that it can be; rather, to me, labels are a different 
animal, but I assumed that everyone knew what they were doing.

Tom Petch 


Thanks,
Acee



There should be a 'when' check to enforce the 'MUST' but the rules of 
YANG do not allow it in this structure.  I raised this on the NETMOD list at 
the time of WGLC and Martin pointed me to a rule in the ABNF which prohibits 
such a check.  He also said that the rule was not needed and would be a 
candidate to remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a 
constraint that must be enforced in the YANG

Tom Petch
>action active-route {
>  description
>"Return the active RIB route that is used for 
the
> destination address.
>
> Address-family-specific modules MUST augment 
input
> parameters with a leaf named 
'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the 
ietf-mpls.yang model should be augmenting the 
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to 
return the address-family specific active-route corresponding to the 
destination-address. This model attempts to overload this RPC with a different 
action all together - returning a route that has the local-label as an optional 
attribute. I'd reject the Errata and believe the augmentation should be removed 
from ietf-mpl.yang. Whether it is replaced with a different one is up to the 
co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "R

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tom, 
I fully understood your original comment. There are other problems with this 
model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return 
the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to 
return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name that 
identifies an entry in RIB to "destination-address" only - in MPLS RIB the 
entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation must have a 
when statement restricting it to AF MPLS. Also, local-label is a leaf which is 
applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing. 

Thanks,
Acee



There should be a 'when' check to enforce the 'MUST' but the rules of YANG 
do not allow it in this structure.  I raised this on the NETMOD list at the 
time of WGLC and Martin pointed me to a rule in the ABNF which prohibits such a 
check.  He also said that the rule was not needed and would be a candidate to 
remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a 
constraint that must be enforced in the YANG

Tom Petch
>action active-route {
>  description
>"Return the active RIB route that is used for the
> destination address.
>
> Address-family-specific modules MUST augment input
> parameters with a leaf named 
'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the 
ietf-mpls.yang model should be augmenting the 
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to 
return the address-family specific active-route corresponding to the 
destination-address. This model attempts to overload this RPC with a different 
action all together - returning a route that has the local-label as an optional 
attribute. I'd reject the Errata and believe the augmentation should be removed 
from ietf-mpl.yang. Whether it is replaced with a different one is up to the 
co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"  wrote:

[Resend to hopefully pass recipient limit filter]

Hi Tom,

I would be interested to hear from the original authors.

My impression is that this is a technically reasonable change, but 
I don't think that an erratum can create a new revision of a YANG module.

If this erratum was processed as "Hold for document update" then 
would that be sufficient to do the right thing in the MPLS YANG module?

Regards,
Rob


> -Original Message-
    > From: tom petch 
> Sent: 10 August 2020 17:32
> To: RFC Errata System ; lho...@nic.cz; 
Acee
> Lindem (acee) ; yingzhen...@huawei.com; 
war...@kumari.net;
> Rob Wilton (rwilton) ; joe...@bogus.com;
> kent+i...@watsen.net; lber...@labn.net
> Cc: ts...@juniper.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
>
> From: netmod  on behalf of RFC Errata 
System
> 
> Sent: 07 August 2020 16:45
>
> 
> This is the erratum of whose arrival I speculated on this list on 
June
> 16th.
>
> There is a degree of urgency about it.  The I-D in question is 
mpls-base-
> yang, currently in IETF Last Call, which is a Normative 
dependency of bfd-
> yang which is a Normative dependency for a small mountain of I-D 
which
> have been waiting a year or so (e.g.  ospf-yang).
>
> I suspect that the technically perfect solution would involve a 
YANG
> union, choice or some such structure but as I said i

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tarek, 

On 8/10/20, 7:27 PM, "Tarek Saad"  wrote:

Hi Acee,

Are you checking https://tools.ietf.org/html/draft-ietf-mpls-base-yang-14?
If so, Figure 2 shows the module is augmenting IPv4/IPv6 AFI with MPLS for 
paths - check the paths
augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
augment 
/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
augment 
/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop:

You'll notice the MPLS augmentation above is applicable for all RIB types 
(including IPv4/IPv6 and the new AFI introduced by this module). The MPLS 
augmentation for IPv4/IPv6 RIBs are specific to IP prefixes that are MPLS 
enabled.

That is how I originally interpreted this augmentation. Precisely, what 
constitutes a route with MPLS enabled? Is it any route for the which the MPLS 
augmentations are applicable or only routes on which they are present?  

You'll also notice draft-ietf-mpls-base-yang is defining a new RIB 
address-family for MPLS as per section 3 in RFC8349 (search for "identity mpls" 
in YANG module).
The new MPLS RIB address-family is meant for "non IP" MPLS routes (e.g. 
MPLS routes installed by RSVP on transit nodes, cross-connects, etc.).

Then what is missing is an augmentation for the destination-prefix that is 
specific to the MPLS AFI. You should not be overloading the local-label which 
applicable to all AFIs is also the destination-prefix for the MPLS AFI. 

 
 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
   when "derived-from-or-self(../../rt:address-family, "
  + "'mpls:mpls')" {
 description
   "This augment is valid only for native MPLS routes.";
   }
   description
 "This leaf augments an native MPLS route.";
   leaf destination-prefix {
 type rt-types:mpls-label;
 description
   "MPLS destination prefix.";
   }
 }

Given the above, can you take another look and let us know?

I think you must follow the AFI specific augmentations set forth in RFC 8349. 
It is not for the augmenting models to break these conventions

One more nit, why is label-block_state not label-block-state? 

Thanks,
Acee





Regards,
Tarek


On 8/10/20, 4:39 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


Hi Tarek,

In that case, there is more wrong than just the RPC since you haven't 
augmented ietf-routing.yang properly to define an MPLS-specific RIB. 
Furthermore, I don't think you should. We need the optional MPLS augmentations 
for the IPv4 and IPv6 address families as these are what one would need in for 
a IPv4 or IPv6 RIB for a device that supports MPLS.

Your augmentation to the active-route RPC needs to just be removed.

Acee

On 8/10/20, 4:24 PM, "Tarek Saad"  wrote:

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to 
return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS 
RIB to return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf 
name that identifies an entry in RIB to "destination-address" only - in MPLS 
RIB the entry leaf name that identifies an entry is "local-label".


>action active-route {
>  description
>"Return the active RIB route that is used 
for the
> destination address.
>
> Address-family-specific modules MUST 
augment input
    > parameters with a leaf named 
'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the 
ietf-mpls.yang model should be augmenting the 
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to 
return the address-family specific active-route corresponding to the 
destination-address. This model attempts to overload this RPC with a different 
action all together - returning a route that has the loca

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tarek, 

In that case, there is more wrong than just the RPC since you haven't augmented 
ietf-routing.yang properly to define an MPLS-specific RIB. Furthermore, I don't 
think you should. We need the optional MPLS augmentations for the IPv4 and IPv6 
address families as these are what one would need in for a IPv4 or IPv6 RIB for 
a device that supports MPLS. 

Your augmentation to the active-route RPC needs to just be removed. 

Acee

On 8/10/20, 4:24 PM, "Tarek Saad"  wrote:

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return 
the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to 
return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name that 
identifies an entry in RIB to "destination-address" only - in MPLS RIB the 
entry leaf name that identifies an entry is "local-label".


>action active-route {
>  description
>"Return the active RIB route that is used for the
> destination address.
>
> Address-family-specific modules MUST augment input
> parameters with a leaf named 
'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the 
ietf-mpls.yang model should be augmenting the 
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to 
return the address-family specific active-route corresponding to the 
destination-address. This model attempts to overload this RPC with a different 
action all together - returning a route that has the local-label as an optional 
attribute. I'd reject the Errata and believe the augmentation should be removed 
from ietf-mpl.yang. Whether it is replaced with a different one is up to the 
co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"  wrote:

[Resend to hopefully pass recipient limit filter]

Hi Tom,

I would be interested to hear from the original authors.

My impression is that this is a technically reasonable change, but 
I don't think that an erratum can create a new revision of a YANG module.

If this erratum was processed as "Hold for document update" then 
would that be sufficient to do the right thing in the MPLS YANG module?

Regards,
Rob


> -Original Message-
    > From: tom petch 
> Sent: 10 August 2020 17:32
> To: RFC Errata System ; lho...@nic.cz; 
Acee
> Lindem (acee) ; yingzhen...@huawei.com; 
war...@kumari.net;
> Rob Wilton (rwilton) ; joe...@bogus.com;
> kent+i...@watsen.net; lber...@labn.net
> Cc: ts...@juniper.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
>
> From: netmod  on behalf of RFC Errata 
System
> 
> Sent: 07 August 2020 16:45
>
> 
> This is the erratum of whose arrival I speculated on this list on 
June
> 16th.
>
> There is a degree of urgency about it.  The I-D in question is 
mpls-base-
> yang, currently in IETF Last Call, which is a Normative 
dependency of bfd-
> yang which is a Normative dependency for a small mountain of I-D 
which
> have been waiting a year or so (e.g.  ospf-yang).
>
> I suspect that the technically perfect solution would involve a 
YANG
> union, choice or some such structure but as I said in my Last 
Call comment
> I can live with a label that contains such as 'address' 
encompassing such
> as 'label' in the context of forwarding.  I take labels to mean 
what
> labels mean rather than what I might find in a work of reference.
>
> Tom Petch
>
> The following errata report has been submitted for RFC8349,
> "A YANG Data Model for Routing Management (NMDA Version)".
>
> 

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

All (Speaking as an author of RFC 8349), 
I just looked at this in more detail and I don't think the ietf-mpls.yang model 
should be augmenting the /rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The 
intent of the RPC is to return the address-family specific active-route 
corresponding to the destination-address. This model attempts to overload this 
RPC with a different action all together - returning a route that has the 
local-label as an optional attribute. I'd reject the Errata and believe the 
augmentation should be removed from ietf-mpl.yang. Whether it is replaced with 
a different one is up to the co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"  wrote:

[Resend to hopefully pass recipient limit filter]

Hi Tom,

I would be interested to hear from the original authors.

My impression is that this is a technically reasonable change, but I don't 
think that an erratum can create a new revision of a YANG module.

If this erratum was processed as "Hold for document update" then would that 
be sufficient to do the right thing in the MPLS YANG module?

Regards,
Rob


> -Original Message-
> From: tom petch 
> Sent: 10 August 2020 17:32
> To: RFC Errata System ; lho...@nic.cz; Acee
> Lindem (acee) ; yingzhen...@huawei.com; war...@kumari.net;
> Rob Wilton (rwilton) ; joe...@bogus.com;
> kent+i...@watsen.net; lber...@labn.net
> Cc: ts...@juniper.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
> 
> From: netmod  on behalf of RFC Errata System
> 
> Sent: 07 August 2020 16:45
> 
> 
> This is the erratum of whose arrival I speculated on this list on June
> 16th.
> 
> There is a degree of urgency about it.  The I-D in question is mpls-base-
> yang, currently in IETF Last Call, which is a Normative dependency of bfd-
> yang which is a Normative dependency for a small mountain of I-D which
> have been waiting a year or so (e.g.  ospf-yang).
> 
> I suspect that the technically perfect solution would involve a YANG
> union, choice or some such structure but as I said in my Last Call comment
> I can live with a label that contains such as 'address' encompassing such
> as 'label' in the context of forwarding.  I take labels to mean what
> labels mean rather than what I might find in a work of reference.
> 
> Tom Petch
> 
> The following errata report has been submitted for RFC8349,
> "A YANG Data Model for Routing Management (NMDA Version)".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6251
> 
> --
> Type: Technical
> Reported by: Tarek Saad 
> 
> Section: 7
> 
> Original Text
> -
> The RPC "active-route" is used to retrieve the active route in a RIB.
> RFC8349 defined two AFIs (v4/v6).
> 
> draft-ietf-mpls-base-yang is defining a new RIB AFI for MPLS as per
> section 3 in RFC8349.
> 
> The RPC has a "MUST" statement that all RIBs must augment input
> parameters with a leaf named 'destination-address'.
> 
> For MPLS RIB, it makes sense to augment with leaf named 'local-label'
> since MPLS routes are identified by MPLS label.
> 
> We ask to make the following change:
> 
> OLD:
>action active-route {
>  description
>"Return the active RIB route that is used for the
> destination address.
> 
> Address-family-specific modules MUST augment input
> parameters with a leaf named 'destination-address'.";
> 
> 
> Corrected Text
> --
> NEW:
>action active-route {
>  description
>"Return the active RIB route that is used for the
> destination address.
> 
> Address-family-specific modules MUST augment input
> parameters with a suitable leaf that identifies the
> route.";
> 
> 
> Notes
> -
> 
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit t

Re: [netmod] rfc6991bis: loopback addresses

[Acee Lindem (acee)]

Hi Qin, 

On 7/30/20, 9:23 PM, "Qin Wu"  wrote:

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2020年7月31日 5:06
收件人: Kent Watsen ; Juergen Schoenwaelder 

抄送: Carlos Pignataro (cpignata) ; netmod@ietf.org
主题: Re: [netmod] rfc6991bis: loopback addresses

Hi Kent,

On 7/30/20, 4:55 PM, "netmod on behalf of Kent Watsen" 
 wrote:


> Thanks for pointing to the definitions in 
draft-nainar-mpls-lsp-ping-yang.
> With that, your request is relatively clear now

Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” 
that constrains inet:ipv[46]-address so that it can only contain loopback 
address values.


> and the question the WG
> needs to answer is whether these types are common enough to warrant 
being
> part of inet-types, i.e., are there any other places where these types
> may be useful?

I don’t think so, but I’m not a routing person.

I wouldn't think that an internal loopback address would be widely used. In 
fact, I checked our Cisco native models for IOS-XE and there is no such 
definition. 

[Qin]: I am not sure we are talking about loopback type or loopback address
See section 2.4 in draft-ietf-netmod-intf-ext-yang-10, 3 type loopbacks are 
defined:
1.Internal loopback
2.Line loopback
3.Loopback Connector
3 types loopback can be classified into local loopback and remote loopback.
I am not sure they are common, but we have some support for this. 

This is the loopback address type - not the loopback interface type. Look at 
draft-nainar-mpls-lsp-ping-yang (the draft being discussed in the Email 
thread). 

Thanks,
Acee

Thanks,
Acee


> /js

K.  // 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

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

Re: [netmod] rfc6991bis: loopback addresses

[Acee Lindem (acee)]

Hi Kent,

On 7/30/20, 4:55 PM, "netmod on behalf of Kent Watsen" 
 wrote:


> Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang.
> With that, your request is relatively clear now

Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” 
that constrains inet:ipv[46]-address so that it can only contain loopback 
address values.


> and the question the WG
> needs to answer is whether these types are common enough to warrant being
> part of inet-types, i.e., are there any other places where these types
> may be useful?

I don’t think so, but I’m not a routing person.

I wouldn't think that an internal loopback address would be widely used. In 
fact, I checked our Cisco native models for IOS-XE and there is no such 
definition. 

Thanks,
Acee


> /js

K.  // 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] Key selection for next hop list in RFC8349

[Acee Lindem (acee)]

Hi Qin,

From: Qin Wu 
Date: Friday, July 10, 2020 at 2:59 AM
To: Acee Lindem 
Cc: NetMod WG 
Subject: Key selection for next hop list in RFC8349

Hi, Acee, Lada, Yingzhen:
In RFC8349, a string type index parameter is defined as the key for next hop 
list, this index has no semantics and can be used as unique ID for each next 
hop entry.
I am wondering why not select next hop address as the key instead of using no 
semantic meaning index? What’s the rationale behind, when we will use index as 
the key, when we will use next hop address as the key?

The model was designed either IPv4 or IPv6 without a requirement on either 
being present. This could not have been done with the next-hop address and 
outgoing interface as the list key.

Hope this helps,
Acee

Thanks in advance.
The following YANG data model snippets is for reference.
 grouping next-hop-content {
   description
 "Generic parameters of next hops in static routes.";
   choice next-hop-options {
 mandatory true;
 description
   "Options for next hops in static routes.

It is expected that further cases will be added through
augments from other modules.";
 case next-hop-list {
   container next-hop-list {
 description
   "Container for multiple next hops.";
 list next-hop {
   key "index";
   description
 "An entry in a next-hop list.
  Modules for address families MUST augment this list
  with a leaf containing a next-hop address of that
  address family.";
   leaf index {
 type string;
 description
   "A user-specified identifier utilized to uniquely
reference the next-hop entry in the next-hop list.
The value of this index has no semantic meaning
other than for referencing the entry.";
   }
   leaf outgoing-interface {
 type if:interface-ref;
 description
   "Name of the outgoing interface.";
   }
 }
   }
 }
   }
 }

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

Re: [netmod] Adoption of versioning design team docs

[Acee Lindem (acee)]

I support adoption of the design team work as well. 
Thanks,
Acee

On 3/9/20, 11:10 AM, "netmod on behalf of Ladislav Lhotka" 
 wrote:

I support the adoption of the entire document set.

Lada
Lou Berger  writes:

> Hi,
> We'd like to start a two week adoption call for the set of documents 
described below by Rob.  To be specific, this includes
> 1) draft-verdt-netmod-yang-solutions-03
> 2) draft-verdt-netmod-yang-module-versioning-01
> 3) draft-verdt-netmod-yang-semver-01
> 4) draft-rwilton-netmod-yang-packages-03
> 5) draft-wilton-netmod-yang-ver-selection-02
> 6) draft-verdt-netmod-yang-schema-comparison-00
>
> The adoption call ends in two weeks, on March 16.
>
> Please voice your support or objections on list.  While we prefer to 
adopt as a set, objections on specific documents are acceptable.
>
> Netmod Chairs
>
> On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote:
>
>> Netmod chairs,
>>
>> The version selection draft draft-wilton-netmod-yang-ver-selection-02 is 
now posted.  With that, the YANG versioning design team would like to please 
request you make an WG adoption call for these documents.
>>
>> The updated full list is:
>>
>> 1) draft-verdt-netmod-yang-solutions-03
>>- Solution overview, updated since 106 to cover updates to version 
selection and schema comparison drafts.
>>
>> 2) draft-verdt-netmod-yang-module-versioning-01
>>- Base module versioning solution, unchanged from the version 
presented at 106.
>>
>> 3) draft-verdt-netmod-yang-semver-01
>>- YANG Semantic version numbers, unchanged from the version presented 
at 106.
>>
>> 4) draft-rwilton-netmod-yang-packages-03
>>- YANG packages draft, updated since 106
>>
>> 5) draft-wilton-netmod-yang-ver-selection-02
>>- Version selection, updated since 106, as per notes below
>>
>> 6) draft-verdt-netmod-yang-schema-comparison-00
>>- Schema comparison tooling, unchanged from the version presented at 
106.
>>
>> The main changes to the version selection draft are:
>>- We have tried to simplify the model, but at the same time give 
servers more flexibility about how they implement version selection and what it 
can be used for.  E.g. if the server wants to allow a client to choose between 
different schema versions, but require that all clients use the same schema 
version, that is now possible
>>- The draft explicitly disallows schema-selection happening 
mid-session
>>- The solution allows the server to require clients to configure 
schema-sets before they are used
>>- The solution provides more information about which schema-sets are 
compatible with each other
>>
>> Regards,
>> 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] ID submission YANG validation errors?

[Acee Lindem (acee)]

Also, the YANG validator tool is broken - 
https://www.yangcatalog.org/yangvalidator/

On 1/22/20, 9:41 AM, "netmod on behalf of Christian Hopps" 
 wrote:


I've just submitted a YANG module draft and received what i think to be a 
bogus validation error:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/

It's saying it can't find the ietf-isis module. Has anyone else experienced 
this issue with referencing draft modules? It seems broken that we can't refer 
to works-in-progress, inside our works-in-progress.

Thanks,
Chris.


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

Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-yang-instance-file-format-04

[Acee Lindem (acee)]

Hi Balazs, 
I think this satisfies all my comments. Please upload the -05 version and I 
will complete the YANG doctors review.
Thanks,
Acee

On 11/6/19, 11:23 AM, "Balázs Lengyel"  wrote:

Hello,
Thanks for the comments and the updated file accordingly.  See below.
Regards Balazs

-Original Message-
From: Acee Lindem via Datatracker  
Sent: 2019. október 30., szerda 13:59
To: yang-doct...@ietf.org
Cc: draft-ietf-netmod-yang-instance-file-format@ietf.org; 
last-c...@ietf.org; netmod@ietf.org
Subject: Yangdoctors last call review of 
draft-ietf-netmod-yang-instance-file-format-04

Reviewer: Acee Lindem
Review result: Ready with Issues

Document: draft-ietf-netmod-yang-instance-file-format-04.txt
Reviewer: Acee Lindem
Review Date: Oct 30st, 2019
Review Type: Working Group Last Call
Intended Status: Standards Track
Summary: Ready with Issues

Modules: "ietf-yang-instance-d...@2019-07-04.yang"

Tech Summary: The model describes mechanisms and statically specifying
  instance data (XML or JSON) for YANG models. Use cases are
  also discussed although not in normative text. The document
  is relatively straight forward but could benefit from some
  editorial cleanup. 

Major Comments:

 None


Minor Comments: 

 1. The "Security Considerations" in section 8 do not conform to the
recommended template in 
https://trac.ietf.org/trac/ops/wiki/yang-security-
guidelines>. The considerations may be completely dependent on the 
included
instance Data Set or some of the information in the model may also be
sensitive. However, it needs to be better described.
BALAZS: Updated security considerations, tried to make it more detailed.
However the template is mostly 
not applicable to  this draft. This draft contains very little own data, 
most of 
the instance data is as you sad completely dependent on the included 
instance Data Set.
It is also planned to be accessed as a file, not via Netconf/Restconf.

 2. I feel it would be helpful to explicitly state that the both read-only
and read-write instance data may be included in the instance data set.
BALAZS: OK. Chapter 3.  Instance Data File Format will include the 
following:
" Config=true and config=false data MAY be mixed in the instance data  
file."

 3. The document could requires some editorial cleanup. For example, use
complete sentenses for principles in section 2.1 and punctuate. Do not
begin sentenses with "E.g. ...". 
BALAZS: Principles reworded.


Nits: 

See diff below.

*** draft-ietf-netmod-yang-instance-file-format-04.txt.orig 2019-10-29 
16:36:22.0 -0400
--- draft-ietf-netmod-yang-instance-file-format-04.txt  
2019-10-29 21:40:06.0 -0400
***
*** 20,26 
 running server available.  This document specifies a standard file
 format for YANG instance data (which follows the syntax and semantic
 from existing YANG models, re-using the same format as the reply to a
! operation/request) and decorates it with metadata.
  
  Status of This Memo
  
--- 20,26 
 running server available.  This document specifies a standard file
 format for YANG instance data (which follows the syntax and semantic
 from existing YANG models, re-using the same format as the reply to a
! operation/request) and annotates it with metadata.
BALAZS: OK
  
  Status of This Memo
  
***
*** 114,127 
  Internet-Draft YANG Instance DataAugust 2019
  
  
!Instance Data Set: A named set of data items decorated with metadata
 that can be used as instance data in a YANG data tree.
  
 Instance Data File: A file containing an instance data set formatted
 according to the rules described in this document.
  
!Content-schema: A set of YANG modules with their revision,suupported
!features and deviations for which the instance data set contains
 instance data
  
 Content defining Yang module(s): YANG module(s) that make up the
--- 114,127 
  Internet-Draft YANG Instance DataAugust 2019
  
  
!Instance Data Set: A named set of data items annotated with metadata
BALAZS: OK
 that can be used as instance data in a YANG data tree.
  
 Instance Data File: A file containing an instance data set formatted
 according to the rules described in this document.
  
!Content-schema: A set of YANG modules with their revision, supported
BALAZS: OK
!features, and deviations for which the 

Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

[Acee Lindem (acee)]

Hi Rob,

Any update on getting the YANG tools issue resolved with the 
ieee802-dot1q-types.yang model in the search path?

Thanks,
Acee

From: netmod  on behalf of "Rob Wilton (rwilton)" 

Date: Tuesday, November 5, 2019 at 4:50 AM
To: Stephen Cheng , "netmod@ietf.org" 

Subject: Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

Hi Stephen,

I’ve just posted an updated version of this document.

The document is in WGLC, and I’m hoping that I can address any outstanding 
comments (including yours) over the next couple of weeks.

Kind regards,
Rob


From: netmod  On Behalf Of Stephen Cheng
Sent: 05 November 2019 02:30
To: netmod@ietf.org
Subject: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model


Authors  of draft-ietf-netmod-sub-intf-vlan-model,

I noticed that the draft has expired, is there any intention to publish a new 
version in new future?

Secondly, I notice a possible problem in the examples in section 7.1/7.2.

In current (expired) draft, in section 7.1. we have in the example

   
 eth0.1
 ianaift:l2vlan
 eth0
 
   
 
   dot1q-types:s-vlan
   10
 

The type of of eth0.1 interface is defined as a l2vlan.

L2vlan is defined in RFC 7224 as follows, which means that l2vlan does not 
derive from ethernetCsmacd nor ieee8023adLag nor ethSubInterface:

identity l2vlan {

   base iana-interface-type;

   description

 "Layer 2 Virtual LAN using 802.1Q.";

 }


However in the current (expired) draft, 
ietf-if-l3-v...@2019-03-05.yang says

 /*

  * Add support for the 802.1Q VLAN encapsulation syntax on layer 3

  * terminated VLAN sub-interfaces.

  */

 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +

 "if-cmn:encaps-type" {

   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,

 'if-cmn:ethSubInterface')" {

 description

   "Applies only to Ethernet-like interfaces and

sub-interfaces";

   }



   description

 "Augment the generic interface encapsulation with an

  basic 802.1Q VLAN encapsulation for sub-interfaces.";



   /*

* Matches a single VLAN Id, or a pair of VLAN Ids to classify

* traffic into an L3 service.

*/

   case dot1q-vlan {

 container dot1q-vlan {

   must

 'count(../../if-cmn:forwarding-mode) = 0 or ' +

 'derived-from-or-self(../../if-cmn:forwarding-mode,' +

   '"if-cmn:layer-3-forwarding")' {

   error-message

 "If the interface forwarding-mode leaf is set then it

  must be set to an identity that derives from

  layer-3-forwarding";



   description

 "The forwarding-mode leaf on an interface can

  optionally be used to enforce consistency of

  configuration";

 }





   description

 "Match VLAN tagged frames with specific VLAN Ids";

   container outer-tag {

 must

   'tag-type = "dot1q-types:s-vlan" or ' +

   'tag-type = "dot1q-types:c-vlan"' {



   error-message

   "Only C-VLAN and S-VLAN tags can be matched";



   description

   "For IEEE 802.1Q interoperability, only C-VLAN and

S-VLAN tags can be matched";

 }



 description

   "Classifies traffic using the outermost VLAN tag on the

frame.";



 uses dot1q-types:dot1q-tag-classifier-grouping;

   }


As such if the type of eth 0.1 is l2vlan should outer-tag etc be available to 
this interface, since l2vlan would not satisfy the “when” clause?

I believe there are similar issues for other interfaces too in section 7.1/7.2 
examples.

Warm regards,
Stephen Cheng

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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Acee Lindem (acee)]

Hi Rob, 
It seems these counters have been considered at great length. I agree we should 
move forward with the model as it is today.
Thanks,
Acee

On 7/17/19, 11:36 AM, "Rob Wilton (rwilton)"  wrote:

Hi Acee,

Thanks for the review, and apologies for the delayed reply.

Regarding your stats question, there was some effort to handle this as part 
of defining the Ethernet interface YANG (IEEE 802.3.2-2019) 
(https://github.com/YangModels/yang/tree/master/standard/ieee/published/802.3) 
that I was involved in the earlier parts of.  Please see the attached XLS that 
was my earlier effort to rationalize the different ethernet interfaces counters 
between RFC 7223, Ethernet YANG, Etherlike MIB, RMON MIBs, and the counters 
exposed in the 802.3 clause 30 management API.

For physical Ethernet interfaces (and anything that looks very similar to a 
physical Ethernet interface) then I think that we should be well covered by the 
combination of what is in ietf-interfaces, and IEEE 802.3.2.

There are also some counters that apply to all Ethernet-like interfaces 
(really anything using Ethernet framing, but not an Ethernet physical layer).  
The only counter currently defined in this category is 
in-drop-unknown-dest-mac-pkts in ietf-interfaces-ethernet-like.  Arguably we 
could also add a drop counter for frames that could not be demuxed to a 
sub-interface because it didn't match any of the sub-interface match 
expressions.

There was one set of counters that 802.3.2 didn't want to include in their 
YANG module which related to the histogram frame statistics.  E.g. counters 
like the following (taken from IOS XR):

Input pkts 65-127 bytes = 0
Input pkts 128-255 bytes= 0
Input pkts 256-511 bytes= 0
Input pkts 512-1023 bytes   = 0
Input pkts 1024-1518 bytes  = 0
Input pkts 1519-Max bytes   = 0

Output pkts 65-127 bytes= 0
Output pkts 128-255 bytes   = 0
Output pkts 256-511 bytes   = 0
Output pkts 512-1023 bytes  = 0
Output pkts 1024-1518 bytes = 0
Output pkts 1519-Max bytes  = 0

The 802.3 YANG WG had two issues with including counters like these:
(1) They didn't really want to define histogram counter values for MTUs 
that are above the officially sanctioned MTU of 1514/1518 in the Ethernet 
specification, even though a lot of hardware supports up to 9K+.
(2) The bucket ranges, at least once you get past the "512-1023" bucket, 
seem to somewhat vary by ASIC vendor.
(3) IEEE 802.3 has a well defined internal management API (802.3 clause 
30), and these histogram counters are not currently defined as part of that 
internal management API.  Extending the internal 802.3 management API seems 
tricky due to point (1) and (2) above.

There was a suggestion in the 802.3 discussions that these counters could 
be defined in an IETF YANG module (skirting the IEEE concerns about maximum 
MTUs).  The proposal was to allow the operational data to return a list of 
bucket entries, where each entry defines the inclusive range of the bucket, and 
a count of the pkts that matched the bucket range (in either the ingress or 
egress direction).  This list would sit alongside a RECOMMENDATION of what 
bucket sizes to use, basically doubling each time up to the MTU, with some 
consideration around the 1514/1518/1522 boundary, but allowing freedom for a 
device to accurately return the histogram ranges actually supported by the 
hardware.

However, I'm not sure it is worth delaying these drafts to add these 
counters in now, particularly because there are dependencies on them.  Possibly 
best done as future work?  Do you, or anyone else in the WG have an opinion on 
this?

Thanks,
Rob



-Original Message-
From: netmod  On Behalf Of Acee Lindem (acee)
Sent: 10 July 2019 14:09
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

I have reviewed the subject document and support publication. I have the 
following comment:

  Perhaps ietf-interface-ethernet-like module 
ethlike:ethernet-like/ethlike:statistics could include a subset of the counters 
from RFC 3635. I say a subset since some of these counters are a bit archaic 
given the state of the technology and judgement should be applied on which to 
include.

  Thanks,
Acee 

On 7/9/19, 8:16 PM, "netmod on behalf of Kent Watsen" 
 wrote:

All,

This starts a twelve-day working group last call for 
draft-ietf-netmod-intf-ext-yang-07

The working group last call ends on July 21 (the day before the NETMOD 
105 sessions).  Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is 

Re: [netmod] Add network instance name on interface, IPv4, IPv6

[Acee Lindem (acee)]

Hi Qin,

From: Qin Wu 
Date: Monday, August 5, 2019 at 10:11 AM
To: "draft-ietf-rtgwg-ni-model@ietf.org" 

Cc: Routing WG , "netmod@ietf.org" , 
"Wangleilei (DOPRA SSP)" 
Subject: Add network instance name on interface, IPv4, IPv6
Resent-From: 
Resent-To: , Christian Hopps , Acee Lindem 
, Dean Bogdanovic , , 
, Jeff Tantsura , Yingzhen 
Qu , Alia Atlas , Martin Vigoureux 
, Deborah Brungard , Alvaro Retana 
, Yingzhen Qu 
Resent-Date: Monday, August 5, 2019 at 10:11 AM

Hi, authors:

In RFC8529, the bind-network-instance-name leaf provides the association 
between an interface and its associated NI.

However it is not clear to me why the same association between Ipv4/Ipv6 type 
and its association NI

Should be provided as well? See model structure snippet defined in RFC8529 as 
follows:
“
   augment /if:interfaces/if:interface:
 +--rw bind-ni-name?   -> /network-instances/network-instance/name
   augment /if:interfaces/if:interface/ip:ipv4:
 +--rw bind-ni-name?   -> /network-instances/network-instance/name
   augment /if:interfaces/if:interface/ip:ipv6:
 +--rw bind-ni-name?   -> /network-instances/network-instance/name
“

So the question is

Can we add different NI name for IPv4/IPv6 type? Isn’t IPv4 type and IPv6 type 
and interface pointing to the same NI name?

Why IPv4 type and IPv6 type in IP data model can not inherit the same NI name 
from the interface model since IP Data model is an extension to Interface Data 
Model?



The model allows the IPv4/IPv6 level of granularity for network-instance 
specification. However, many, if not most, implementations do not. My memory is 
hazy as to which implementation(s) supports this.

Thanks,
Acee








Suppose we configure interface and associated IP addresses and assign this 
interface to a NI,
Which configuration snippet is correct:
Option A:
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
"ietf-network-instance:bind-network-instance-name": "vrf-red"
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
"ietf-network-instance:bind-network-instance-name": "vrf-red"
},
"ietf-network-instance:bind-network-instance-name": "vrf-red"
},
Option B:
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
},
"ietf-network-instance:bind-network-instance-name": "vrf-red"
},

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

Re: [netmod] HTTP: or HTTPS:

[Acee Lindem (acee)]

On 7/31/19, 7:09 AM, "netmod on behalf of Ladislav Lhotka" 
 wrote:

On Wed, 2019-07-31 at 11:00 +, tom petch wrote:
> YANG modules contain several URL - e.g. for the Working Group,  Legal
> provisions, RFC - for which some authors use http:, some use https: and
> some use a mixture.
> 
> Should we be recommending the use of https: in all cases?

Yes, given that the http: URLs now return 404.

Agreed. Perhaps, there should be an errata on the RFC 8407 template. 

https://tools.ietf.org/html/rfc8407#appendix-B

Thanks,
Acee

Lada

> 
> Tom Petch
> 
> ___
> 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] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05

[Acee Lindem (acee)]

I've reviewed this document and support publication. I don’t have comments on 
the module per se. However, the IETF tools need to include the IEEE YANG model 
needed for successful validation. 
Thanks,
Acee

On 7/9/19, 8:15 PM, "netmod on behalf of Kent Watsen"  wrote:

All,

This starts a twelve-day working group last call for 
draft-ietf-netmod-sub-intf-vlan-model-05.

The working group last call ends on July 21 (the day before the NETMOD 105 
sessions).  Please send your comments to the working group 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.

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-intf-ext-yang-07

[Acee Lindem (acee)]

I have reviewed the subject document and support publication. I have the 
following comment:

  Perhaps ietf-interface-ethernet-like module 
ethlike:ethernet-like/ethlike:statistics could include a subset of the counters 
from RFC 3635. I say a subset since some of these counters are a bit archaic 
given the state of the technology and judgement should be applied on which to 
include.

  Thanks,
Acee 

On 7/9/19, 8:16 PM, "netmod on behalf of Kent Watsen"  wrote:

All,

This starts a twelve-day working group last call for 
draft-ietf-netmod-intf-ext-yang-07

The working group last call ends on July 21 (the day before the NETMOD 105 
sessions).  Please send your comments to the working group 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.

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] 6021 ipv4-prefix

[Acee Lindem (acee)]

Hi Juergen, 

On 4/26/19, 11:36 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

On Fri, Apr 26, 2019 at 05:07:52PM +0200, Kristian Larsson wrote:
> 
> I think the canonical representation is quite clear as is the part that 
the
> server must return data (and conceptually store) in canonical format. What
> is much less clear is the allowed input formats which then includes
> 2001:db8::1/64. I think it could be worthwhile to explicitly state this as
> it is a bit surprising. Unlike say the uintX types, there is no "lexical
> representation" section for ip-prefix (I presume because they are not
> basetypes and so the lexical presentation follows the base, string in this
> case + the pattern) that explains things in any detail. Do you think we
> could add some clarifications, perhaps to the description of the type 
about
> this? Or could we even add a lexical representation section with examples?
> Or just an examples section?
>

I have added text along these lines in my sources (goes behind the
definition of the canonical format):

  The definition of ipv6-prefix does not require that bits,
  which are not part of the prefix, are set to zero. However,
  implementations have to return values in canonical format,
  which requires non-prefix bits to be set to zero. This means
  that 2001:db8::1/64 must be accepted as a valid value but it
  will be converted into the canonical format 2001:db8::/64.

I have added similar text to the definition of ipv4-prefix. I hope
that text like this clarifies the situation inline in the type
definition.

I must admit that I think this is the worst possible outcome. Independent of 
the original intent, at a high level it is just not a good idea to accept the 
non-canonical prefix format and return the canonical format. 

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

Re: [netmod] 6021 ipv4-prefix

[Acee Lindem (acee)]

Agreed. 

Thanks,
Acee

On 4/26/19, 1:52 AM, "netmod on behalf of Jeff Tantsura" 
 wrote:

+1

Cheers,
Jeff

> On Apr 18, 2019, at 6:12 AM, Lou Berger  wrote:
> 
> Having worked with UIs that have the behavior of accepting an 
address/prefix-len and mapping it to a prefix, (i.e., network/prefix-len and 
zeroing out the non-significant bits)  - some users really like it as they 
don't have to do the transformation from address to network, notably for odd 
length prefixes, while other users hate it as the system shows/does something 
different than what they entered.
> 
> In the end the current definition is what it is.  If we want something 
different we can define it. I personally think an address/prefix-len would be 
useful, and would leave ip-prefix as is.  (again just an individual's opinion.)
> 
> Lou
> 
>> On 4/18/2019 6:53 AM, Mikael Abrahamsson wrote:
>>> On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
>>> 
 On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
 
 2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them.
>>> Why are they not the same if you define a prefix?
>> Because they're not. One of them is a valid prefix, the other one isn't.
>> 
>>> +17.4 is not an integer, so this is an error (not because of the + but
>>> because of the . followed by additional digits). +17 is I think a valid
>>> integer value but the + will be dropped in the canonical representation.
>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
>> the prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>> rounded if an integer input is expected?
>> 
> 
> ___
> 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] 6021 ipv4-prefix

[Acee Lindem (acee)]

Hi Mikael,

On 4/18/19, 3:17 AM, "netmod on behalf of Mikael Abrahamsson" 
 wrote:

On Tue, 16 Apr 2019, 7ri...@gmail.com wrote:

> We might need to clarify this with the libyang folk.

I see that Michal fixed the bug in libyang. Good.

There is another thing I am unsure about.

What is the netconf server supposed to do if a client tries to store 
192.168.1.1/24 in ipv4-prefix ? Or 2001:db8::1/64 in ipv6-prefix?

Since the constraint on the non-masked portion of the prefix is solely in the 
description, there is nothing to prevent this and I'm sure the ipv4-prefix and 
ipv6-prefix types are being used incorrectly.

Thanks,
Acee


Reading the canonical format description in 6021 one might intepret that 
the netconf server should just truncate the host bits and store these as 
192.168.1.0/24 and 2001:db8::/64 ? This means the netconf server actually 
stored something else than the client tried to commit (the resulting 
uint32 and uint128 will have different information than was commited by 
the netconf client).

Or should the netconf server throw an error if the client tries to commit 
data that is not according to the bit pattern described in the canonical 
format?

I guess I am getting confused by the "canonical format" term being used in 
IPv6 for describing the ascii representation of the value, but both in 
IPv4 and IPv6 it's also used to describe how the bits should be set (and 
not be set) depending on prefix/mask.

Also, the IPv4 canoncical format representation doesn't describe at all 
the ascii representation, so for instance 192.168.001.001 would be valid 
according to 6021. I haven't seen this to be a problem in reality though, 
because IPv4 addresses are typically "compressed" the same way, all the 
time. If we're revving 6021, then perhaps some text about ascii 
representation format should be to use the format used by the posix 
function inet_ntoa() ?

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

___
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] Doubts about static routes in RFC 8349

[Acee Lindem (acee)]

Hi Martin, 

On 4/3/19, 7:57 AM, "Martin Bjorklund"  wrote:

"Acee Lindem (acee)"  wrote:
> Hi Sasha, 
> 
> On 4/3/19, 7:27 AM, "Alexander Vainshtein"
>  wrote:
> 
> Martin,
> Lots of thanks for a prompt response.
> 
> My reading of your response is that, if you need multiple static
> routes with the same destination but different next hops, you
> configure them as a single route with next-hop-list, but what you see
> when you retrieve the RIB may be multiple individual routes, each with
> its own simple next hop. Or it may be something else, since no keys
> have been defined in the read-only representation of the RIB.
> 
> Is my reading correct?
> 
> No - you'd see a single route and next-hop-list with the alternatives
> when it is retrieved.

Do you think it would be a violation of the spec if an implementation
expanded this into several route entries?  If yes, is this specified?

Normally, a given RIB client, e.g., static,  would install a single route with 
one or more next-hops in the global RIB. If present, multiple routes for the 
same destination would come from different RIB clients. The RIB active route 
the is the route with the lowest preference value (more preferred). Since the 
read-only lists do not have indices, I don't see how'd we'd enforce this. 
However, an implementation supporting any other structure would be highly 
irregular. 

Thanks,
Acee


/martin



>  
> Thanks,
> Acee
>  
> 
> Regards, and lots of thanks in advance,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> -Original Message-
> From: Martin Bjorklund  
> Sent: Wednesday, April 3, 2019 2:05 PM
> To: Alexander Vainshtein 
> Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
> 
> Hi,
> 
> 
> Alexander Vainshtein  wrote:
> > Martin,
> > 
> > Lots of thanks for an interesting input.
> > 
> > I have noticed that Appendix A in RFC
> > 8349<https://tools.ietf.org/html/rfc8349#appendix-A>  defines the 
key 
> > for static IPv4 and IPv6 unicast routes as “destination-prefix”.
> 
> Right (to be precise, the key is defined in the YANG models in section
> 8 and 9).
> 
> 
> > draft-ietf-rtgwg-
> > 
yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-
> > extend-01> claims that it augments the model defined in 8349, 
> > therefore, to the best of my understanding, it uses the same key 
for 
> > station IPv4 and
> > IPv6 unicast routes.
> 
> Correct.
> 
> 
> > At the same time Appendix A in this draft does not define any keys 
for
> > the read-only RIB.
> > 
> > Can you explain this controversy?
> 
> Not sure there's a controversy.  The static route list is how you
> configure static routes, and the RIB is the operational state of all
> routes (static and others).  Two different things.
> 
> The MIB had a single table to show routes and write routes.  I don't
> think the persistency of the routes you wrote into the MIB was
> defined; perhaps these can be viewed as being "static".
> 
> 
> /martin
> 
> 
> > 
> > 
> > 
> > Regards, and lots of thanks in advance,
> > 
> > Sasha
> > 
> > 
> > 
> > Office: +972-39266302
> > 
> > Cell:  +972-549266302
> > 
> > Email:   alexander.vainsht...@ecitele.com
> > 
> > 
> > 
> > -Original Message-
> > From: Martin Bjorklund 
> > Sent: Wednesday, April 3, 2019 1:34 PM
> > To: Alexander Vainshtein 
> > Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> > Subject: Re: [netmod] Doubts about static routes in RFC 8349
> > 
> > 
> > 
> 

Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

[Acee Lindem (acee)]

Hi Sasha,
Although we are providing the same or better functionality, we never had 
mimicking the RFC 4292 MIB structure as a requirement. IMO, this would be a 
mistake since SNMP doesn’t allow nesting of tables while YANG, OTOH, supports 
arbitrary nesting of schema. We really must exploit this key advantage in our 
models.

Thanks,
Acee

From: Alexander Vainshtein 
Date: Wednesday, April 3, 2019 at 3:14 AM
To: Acee Lindem , Ladislav Lhotka 
Cc: Routing WG , "netmod@ietf.org" 
Subject: RE: Doubts about static routes in RFC 8349 (was: Doubts about static 
routes in RFC 8022)

Acee,
Lots of thanks for a prompt response with a highly relevant pointer.

I will read 
draft-ietf-rtgwg-yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-extend-01>
 and probably send more questions.

Meanwhile, could you please explain the rationale for changing the data model 
that has been defined in RFC 4292 (where both the destination prefix and the 
next hop have been parts of the index in the appropriate MIB table) ?

The side effect of this change is  that it is not backward-compatible with 
multiple existing RFC 4292-compliant RIB implementations:

-  Retrieval of such a RIB using YANG requires a stateful mapper that 
merges multiple RIB entries with the same destination prefix and different 
“simple” NH into a single entry with the next-hop-list

-  Configuration of a single static route that uses the next-hop-list 
requires a mapper that splits such a list into multiple 4292-compliant routes 
(simpler than merge, but still non-trivial IMHO).

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Acee Lindem (acee) 
Sent: Tuesday, April 2, 2019 7:45 PM
To: Alexander Vainshtein ; lho...@nic.cz
Cc: rt...@ietf.org; netmod@ietf.org
Subject: Re: Doubts about static routes in RFC 8349 (was: Doubts about static 
routes in RFC 8022)

Hi Sasha,
You are correct that there is no per-next-hop preference in the current model. 
However, this is included in the augmentation in 
draft-ietf-rtgwg-yang-rib-extend.
Thanks,
Acee

From: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>
Date: Tuesday, April 2, 2019 at 9:53 AM
To: Acee Lindem mailto:a...@cisco.com>>, Ladislav Lhotka 
mailto:lho...@nic.cz>>
Cc: Routing WG mailto:rt...@ietf.org>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
mailto:netmod@ietf.org>>
Subject: Doubts about static routes in RFC 8349 (was: Doubts about static 
routes in RFC 8022)

Hi all,
I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the 
same problem.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: 'a...@cisco.com' mailto:a...@cisco.com>>; 'lho...@nic.cz' 
mailto:lho...@nic.cz>>
Cc: 'rt...@ietf.org' mailto:rt...@ietf.org>>; 'netmod@ietf.org' 
mailto:netmod@ietf.org>>
Subject: Doubts about static routes in RFC 8022
Importance: High

Acee, Ladislav and all,
I have serious doubts regarding the data model for static routes in RFC 8022.

As I see it, the data model defined in this document does not support multiple 
routes with common destination, different next hops and different route 
preferences.

This is because only route destination is considered as the key in the RIB in 
Appendix A of RFC 8022., while route preference is a per-route read-only leaf 
in the data model.

In particular (and this was my original problem) , it is possible to configure 
a static route with multiple next hops (using the next-hop-list construct) 
using the data model defined in RFC 8022, but all the next hops in this 
construct would have the same preference. AFAIK, many (if not all) deployed 
implementations support ability to configure static routes with the same 
destination, different next hops and different preferences, so that one of 
these next hops would act as a protection of the other.

For the reference, this problem does not exist in the standard MIB for the RIB 
(RFC 4292), because it includes both the route destination and its next hop in 
the list  of indices in the corresponding MIB.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

Re: [netmod] Doubts about static routes in RFC 8349

[Acee Lindem (acee)]

Hi Sasha, 

On 4/3/19, 7:27 AM, "Alexander Vainshtein"  
wrote:

Martin,
Lots of thanks for a prompt response.

My reading of your response is that, if you need multiple static routes 
with the same destination but different next hops, you configure them as a 
single route with next-hop-list, but what you see when you retrieve the RIB may 
be multiple individual routes, each with its own simple next hop. Or it may be 
something else, since no keys have been defined in the read-only representation 
of the RIB.

Is my reading correct?

No - you'd see a single route and next-hop-list with the alternatives when it 
is retrieved. 
 
Thanks,
Acee
 

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


-Original Message-
From: Martin Bjorklund  
Sent: Wednesday, April 3, 2019 2:05 PM
To: Alexander Vainshtein 
Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
Subject: Re: [netmod] Doubts about static routes in RFC 8349

Hi,


Alexander Vainshtein  wrote:
> Martin,
> 
> Lots of thanks for an interesting input.
> 
> I have noticed that Appendix A in RFC
> 8349  defines the key 
> for static IPv4 and IPv6 unicast routes as “destination-prefix”.

Right (to be precise, the key is defined in the YANG models in section
8 and 9).


> draft-ietf-rtgwg-
> yang-rib-extend extend-01> claims that it augments the model defined in 8349, 
> therefore, to the best of my understanding, it uses the same key for 
> station IPv4 and
> IPv6 unicast routes.

Correct.


> At the same time Appendix A in this draft does not define any keys for 
> the read-only RIB.
> 
> Can you explain this controversy?

Not sure there's a controversy.  The static route list is how you configure 
static routes, and the RIB is the operational state of all routes (static and 
others).  Two different things.

The MIB had a single table to show routes and write routes.  I don't think 
the persistency of the routes you wrote into the MIB was defined; perhaps these 
can be viewed as being "static".


/martin


> 
> 
> 
> Regards, and lots of thanks in advance,
> 
> Sasha
> 
> 
> 
> Office: +972-39266302
> 
> Cell:  +972-549266302
> 
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> 
> -Original Message-
> From: Martin Bjorklund 
> Sent: Wednesday, April 3, 2019 1:34 PM
> To: Alexander Vainshtein 
> Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
> 
> 
> 
> Hi,
> 
> 
> 
> Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
> 
> 
> 
> [...]
> 
> 
> 
> > Meanwhile, could you please explain the rationale for changing the
> 
> > data model that has been defined in RFC 4292 (where both the
> 
> > destination prefix and the next hop have been parts of the index in
> 
> > the appropriate MIB table) ?
> 
> >
> 
> > The side effect of this change is that it is not backward-compatible
> 
> > with multiple existing RFC 4292-compliant RIB implementations:
> 
> >
> 
> > -  Retrieval of such a RIB using YANG requires a stateful 
mapper that
> 
> >merges multiple RIB entries with the same destination 
> > prefix and
> 
> >different “simple” NH into a single entry with the
> 
> >next-hop-list
> 
> 
> 
> Note that the "route" list in the rib doesn't have any keys.  This means 
that you can report several entries with the same destination prefix.  So I 
think that this design is compatible with the MIB design.
> 
> 
> 
> 
> 
> 
> 
> /martin
> 
> __
> _
> 
> This e-mail message is intended for the recipient only and contains 
> information which is CONFIDENTIAL and which may be proprietary to ECI 
> Telecom. If you have received this transmission in error, please 
> inform us by e-mail, phone or fax, and then delete the original and all 
copies thereof.
> __
> _

___

This e-mail message is intended for the recipient only and contains 
information which is 
CONFIDENTIAL and which may be proprietary to ECI 

Re: [netmod] Doubts about static routes in RFC 8349

[Acee Lindem (acee)]

Hi Sasha, Martin, 

Just one clarification below. 

On 4/3/19, 7:05 AM, "Martin Bjorklund"  wrote:

Hi,


Alexander Vainshtein  wrote:
> Martin,
> 
> Lots of thanks for an interesting input.
> 
> I have noticed that Appendix A in RFC
> 8349  defines the
> key for static IPv4 and IPv6 unicast routes as
> “destination-prefix”.

Right (to be precise, the key is defined in the YANG models in section
8 and 9).


> draft-ietf-rtgwg-
> 
yang-rib-extend
> claims that it augments the model defined in 8349, therefore, to the
> best of my understanding, it uses the same key for station IPv4 and
> IPv6 unicast routes.

Correct.

The way multiple alternatives are supported is via the existing RFC 8349 
next-hop-list list.
This is keyed with an index. What the augmentation provides is a way to specify 
a
preference for each next hop so that either ECMP or primary/backup uses case can
be supported. It is clear I need to expand the descriptive text for these 
augmentations
in the draft-ietf-rtgwg-yang-rib-extend. 

Thanks,
Acee


> At the same time Appendix A in this draft does not define any keys
> for the read-only RIB.
> 
> Can you explain this controversy?

Not sure there's a controversy.  The static route list is how you
configure static routes, and the RIB is the operational state of all
routes (static and others).  Two different things.

The MIB had a single table to show routes and write routes.  I don't
think the persistency of the routes you wrote into the MIB was
defined; perhaps these can be viewed as being "static".


/martin


> 
> 
> 
> Regards, and lots of thanks in advance,
> 
> Sasha
> 
> 
> 
> Office: +972-39266302
> 
> Cell:  +972-549266302
> 
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> 
> -Original Message-
> From: Martin Bjorklund 
> Sent: Wednesday, April 3, 2019 1:34 PM
> To: Alexander Vainshtein 
> Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
> 
> 
> 
> Hi,
> 
> 
> 
> Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
> 
> 
> 
> [...]
> 
> 
> 
> > Meanwhile, could you please explain the rationale for changing the
> 
> > data model that has been defined in RFC 4292 (where both the
> 
> > destination prefix and the next hop have been parts of the index in
> 
> > the appropriate MIB table) ?
> 
> >
> 
> > The side effect of this change is that it is not backward-compatible
> 
> > with multiple existing RFC 4292-compliant RIB implementations:
> 
> >
> 
> > -  Retrieval of such a RIB using YANG requires a stateful 
mapper that
> 
> >merges multiple RIB entries with the same destination prefix 
and
> 
> >different “simple” NH into a single entry with the
> 
> >next-hop-list
> 
> 
> 
> Note that the "route" list in the rib doesn't have any keys.  This means 
that you can report several entries with the same destination prefix.  So I 
think that this design is compatible with the MIB design.
> 
> 
> 
> 
> 
> 
> 
> /martin
> 
> 
___
> 
> This e-mail message is intended for the recipient only and contains 
information which is 
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this 
> transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
> and all copies thereof.
> 
___


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

Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

[Acee Lindem (acee)]

Hi Sasha,
You are correct that there is no per-next-hop preference in the current model. 
However, this is included in the augmentation in 
draft-ietf-rtgwg-yang-rib-extend.
Thanks,
Acee

From: Alexander Vainshtein 
Date: Tuesday, April 2, 2019 at 9:53 AM
To: Acee Lindem , Ladislav Lhotka 
Cc: Routing WG , "netmod@ietf.org" 
Subject: Doubts about static routes in RFC 8349 (was: Doubts about static 
routes in RFC 8022)

Hi all,
I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the 
same problem.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: 'a...@cisco.com' ; 'lho...@nic.cz' 
Cc: 'rt...@ietf.org' ; 'netmod@ietf.org' 
Subject: Doubts about static routes in RFC 8022
Importance: High

Acee, Ladislav and all,
I have serious doubts regarding the data model for static routes in RFC 8022.

As I see it, the data model defined in this document does not support multiple 
routes with common destination, different next hops and different route 
preferences.

This is because only route destination is considered as the key in the RIB in 
Appendix A of RFC 8022., while route preference is a per-route read-only leaf 
in the data model.

In particular (and this was my original problem) , it is possible to configure 
a static route with multiple next hops (using the next-hop-list construct) 
using the data model defined in RFC 8022, but all the next hops in this 
construct would have the same preference. AFAIK, many (if not all) deployed 
implementations support ability to configure static routes with the same 
destination, different next hops and different preferences, so that one of 
these next hops would act as a protection of the other.

For the reference, this problem does not exist in the standard MIB for the RIB 
(RFC 4292), because it includes both the route destination and its next hop in 
the list  of indices in the corresponding MIB.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

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

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

[Acee Lindem (acee)]

Hi Rob, 

On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)" 
 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-prefix type represents an IPv4 address prefix.
> 
> so having a type ipv4-address-prefix for something that is not (only) an
> "ipv4 address prefix" is imo confusing.
> 
> 
> /martin
> 
> 
> 
> 
> >
> > /js
> >
> > On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> > > - Original Message -
> > > From: "Jeff Tantsura" 
> > > To: ; "Kristian Larsson" 
> > > Sent: Monday, April 01, 2019 11:09 PM
> > >
> > > What Kristian has proposed makes sense, in favor.
> > >
> > > 
> > >
> > > Yes, I support this idea and we should be able to come up with a
> > > more user-friendly name;  address-prefix or address-length ?
> > >
> > > Tom Petch
> > >
> > > p.s.
> > >
> > >identifier  = (ALPHA / "_")
> > >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > >
> > > Cheers,
> > > Jeff
> > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> > > , wrote:
> > > > Hello Mahesh,
> > > >
> > > > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> > > > >
> > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund 
> > > wrote:
> > > > > >
> > > > > > I know that this type is convenient, esp. if you use it for
> > > > > > manual input, but I wonder if it really is good practice to
> > > > > > squeeze two values into one.
> > > > >
> > > > > Agree. The combination makes sense for CLI, but for modeling the
> > > address and prefix should be separate.
> > > >
> > > > Okay, then why do we have an ip-prefix data type at all? With the
> > > > same line of argument you apply, it should be split up.
> > > >
> > > > So you're the third person bringing up CLI. I don't get this at
> > > > all. I don't see how CLI are different from everything else. This
> > > > is about
> > > data
> > > > modeling and data modeling is about expressing the world in a data
> > > > modeling language. It's like painting a picture but instead of a
> > > > brush you have a schema language like YANG. What do you see?
> > > > Express it. It doesn't matter if the purpose is a CLI, a web page
> > > > or just exposing it via NETCONF for another system to consume.
> > > >
> > > > I think address-and-prefix-length is natural. JUNOS uses this 
format.
> > > XR
> > > > uses this format (for IPv6 at least). Nokia SROS uses this format.
> > > >
> > > > We have written a bunch of models where the lack of this IMHO
> > > > makes
> > > them
> > > > less elegant. I'd like for there to be an IETF standard data type
> > > > to make those models more elegant.
> > > >
> > > > Kind regards,
> > > > Kristian.
> > > >
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > 

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

[Acee Lindem (acee)]

Hi Kristian,
Ok - I see that even though the existing ipv4-prefi type requires all 4 octets 
of the address, the description indicates that the host portion must be zero in 
the canonical format. Now that I understand your requirement, I'm in favor of 
adding a type that removes this restriction (i.e., the last statement in the 
description). 
Thanks,
Acee

On 4/1/19, 3:40 PM, "Kristian Larsson"  wrote:



On 2019-04-01 19:38, Acee Lindem (acee) wrote:
> 
> On 4/1/19, 1:30 PM, "Martin Bjorklund"  wrote:
> 
>  Hi,
>  
>  The request was for a combined type that contains both an ip address
>  *and* a prefix length in one value.  Hence the name
>  "ip-address-and-prefix-length" :)
> 
> Ok - I understand now.
>  
>  I know that this type is convenient, esp. if you use it for manual
>  input, but I wonder if it really is good practice to squeeze two
>  values into one.
> 
> Agreed. It seems a prefix with a prefix length of 32 for IPv4 or 128 for 
IPv6 would allow specification.

No, it does not. You must be referring to some other use case. I want to 
configure the IP address and prefix-length on an interface. The 
prefix-length naturally needs to align with the prefix-length / subnet 
mask used on the network to which the interface is connected. If it is a 
/24 network then the prefix-length needs to be 24. I can't just say it's 
a /32 so I can enter this information - the router wouldn't understand 
what is then connected to that network / interface and wouldn't be able 
to route packets correctly.

At the same time, I need to specify the exact IP address to be used by 
this device on the interface, so I need to have bits set to the right of 
the mask, thus I can't use current ip-prefix type.


> The convenience is primarily for mapping to CLI.

Heh, I don't understand what it has to do with CLI but since you're the 
second person mentioning there must be some connection I don't see.
    
Kind regards,
Kristian.




>  "Acee Lindem (acee)"  wrote:
>  > Ok, now I'm confused. I see that the ietf-inet-type model already 
has the types ipv4-prefix and ipv6-prefix. How are these any different???
>  > Thanks,
>  > Acee
>  >
>  > On 4/1/19, 12:31 PM, "Acee Lindem (acee)"  wrote:
>  >
>  > I believe the "address-" could be omitted from the type 
identifiers. At least within the routing area, "ipv4-prefix" is unambiguous.
>  > Thanks,
>  > Acee
>  >
>  > On 4/1/19, 12:14 PM, "netmod on behalf of Juergen 
Schoenwaelder"  wrote:
>  >
>  > This is the right time for this and I would call these
>  > ip-address-prefix, ipv4-address-prefix and ipv6-address
>  > prefix.
>  >
>  > /js
>  >
>  > On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson 
wrote:
>  > > Hello,
>  > >
>  > > seeing that 6991 is up for a refresh I wonder if this 
would be the time to
>  > > suggest the addition of a type for 
address-and-prefix-length, for example
>  > > like 192.0.2.1/24?
>  > >
>  > > I find that it's the most natural way express the 
address and prefix-length
>  > > to configure on an interface or for some other use. We 
currently have an
>  > > ip-prefix type which allows CIDR style prefixes but 
since all bits to the
>  > > right of the mask is to be 0 it is only possible to use 
for describing the
>  > > IP prefix / network address itself - not the address of 
a host in that
>  > > network.
>  > >
>  > > I actually wish the interface-ip modules would have used 
a combined leaf for
>  > > these settings rather than the dual-leaf approach it 
currently has, but I
>  > > suppose that ship has sailed :/
>  > >
>  > > Regardless, can we add such a type? Is this the document 
and time to do it?
>  > > :)
>  > >
>  > > Kind regard,
>  > >Kristian.
>  > >
>  > > _

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

[Acee Lindem (acee)]

On 4/1/19, 1:30 PM, "Martin Bjorklund"  wrote:

Hi,

The request was for a combined type that contains both an ip address
*and* a prefix length in one value.  Hence the name
"ip-address-and-prefix-length" :)

Ok - I understand now. 

I know that this type is convenient, esp. if you use it for manual
input, but I wonder if it really is good practice to squeeze two
values into one.

Agreed. It seems a prefix with a prefix length of 32 for IPv4 or 128 for IPv6 
would allow specification. The convenience is primarily for mapping to CLI.

Thanks,
Acee


/martin

    
    "Acee Lindem (acee)"  wrote:
> Ok, now I'm confused. I see that the ietf-inet-type model already has the 
types ipv4-prefix and ipv6-prefix. How are these any different??? 
> Thanks,
> Acee
    > 
    > On 4/1/19, 12:31 PM, "Acee Lindem (acee)"  wrote:
> 
> I believe the "address-" could be omitted from the type identifiers. 
At least within the routing area, "ipv4-prefix" is unambiguous. 
> Thanks,
> Acee
> 
> On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:
> 
> This is the right time for this and I would call these
> ip-address-prefix, ipv4-address-prefix and ipv6-address
> prefix.
> 
> /js
> 
> On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
> > Hello,
> > 
> > seeing that 6991 is up for a refresh I wonder if this would be 
the time to
> > suggest the addition of a type for address-and-prefix-length, 
for example
> > like 192.0.2.1/24?
> > 
> > I find that it's the most natural way express the address and 
prefix-length
> > to configure on an interface or for some other use. We 
currently have an
> > ip-prefix type which allows CIDR style prefixes but since all 
bits to the
> > right of the mask is to be 0 it is only possible to use for 
describing the
> > IP prefix / network address itself - not the address of a host 
in that
> > network.
> > 
> > I actually wish the interface-ip modules would have used a 
combined leaf for
> > these settings rather than the dual-leaf approach it currently 
has, but I
> > suppose that ship has sailed :/
> > 
> > Regardless, can we add such a type? Is this the document and 
time to do it?
> > :)
> > 
> > Kind regard,
> >Kristian.
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany
> Fax:   +49 421 200 3103 
<https://www.jacobs-university.de/>
> 
> ___
> 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] 6991bis: address-with-prefix-length

[Acee Lindem (acee)]

Ok, now I'm confused. I see that the ietf-inet-type model already has the types 
ipv4-prefix and ipv6-prefix. How are these any different??? 
Thanks,
Acee

On 4/1/19, 12:31 PM, "Acee Lindem (acee)"  wrote:

I believe the "address-" could be omitted from the type identifiers. At 
least within the routing area, "ipv4-prefix" is unambiguous. 
Thanks,
Acee

On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

This is the right time for this and I would call these
ip-address-prefix, ipv4-address-prefix and ipv6-address
prefix.

/js

On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
> Hello,
> 
> seeing that 6991 is up for a refresh I wonder if this would be the 
time to
> suggest the addition of a type for address-and-prefix-length, for 
example
> like 192.0.2.1/24?
> 
> I find that it's the most natural way express the address and 
prefix-length
> to configure on an interface or for some other use. We currently have 
an
> ip-prefix type which allows CIDR style prefixes but since all bits to 
the
> right of the mask is to be 0 it is only possible to use for 
describing the
> IP prefix / network address itself - not the address of a host in that
> network.
> 
> I actually wish the interface-ip modules would have used a combined 
leaf for
> these settings rather than the dual-leaf approach it currently has, 
but I
> suppose that ship has sailed :/
> 
> Regardless, can we add such a type? Is this the document and time to 
do it?
> :)
> 
> Kind regard,
>Kristian.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

___
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] 6991bis: address-with-prefix-length

[Acee Lindem (acee)]

I believe the "address-" could be omitted from the type identifiers. At least 
within the routing area, "ipv4-prefix" is unambiguous. 
Thanks,
Acee

On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

This is the right time for this and I would call these
ip-address-prefix, ipv4-address-prefix and ipv6-address
prefix.

/js

On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
> Hello,
> 
> seeing that 6991 is up for a refresh I wonder if this would be the time to
> suggest the addition of a type for address-and-prefix-length, for example
> like 192.0.2.1/24?
> 
> I find that it's the most natural way express the address and 
prefix-length
> to configure on an interface or for some other use. We currently have an
> ip-prefix type which allows CIDR style prefixes but since all bits to the
> right of the mask is to be 0 it is only possible to use for describing the
> IP prefix / network address itself - not the address of a host in that
> network.
> 
> I actually wish the interface-ip modules would have used a combined leaf 
for
> these settings rather than the dual-leaf approach it currently has, but I
> suppose that ship has sailed :/
> 
> Regardless, can we add such a type? Is this the document and time to do 
it?
> :)
> 
> Kind regard,
>Kristian.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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


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

Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

[Acee Lindem (acee)]

I support WG adoption.
Acee

From: netmod  on behalf of Kent Watsen 

Date: Monday, March 25, 2019 at 4:31 PM
To: "netmod@ietf.org" 
Subject: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

This email begins a 2-week adoption poll for:


https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00


Please voice your support or objections before April 8.


Kent (and Lou and Joel)

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

Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

From: netmod  on behalf of Kent Watsen 

Date: Monday, March 25, 2019 at 4:33 PM
To: "netmod@ietf.org" 
Subject: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

This email begins a 2-week adoption poll for:


https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01


Please voice your support or objections before April 8.


Kent // as co-chair



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

Re: [netmod] for a future rfc6991bis

[Acee Lindem (acee)]

Hi Tom, Juergen, 
I agree with Juergen - we went through this discussion with ietf-routing-types 
(RFC 8294) and came to the same conclusion. We kept, the generic 
link-access-type enum but I believe it is, heretofore, unused. 
Thanks,
Acee

On 12/31/18, 7:48 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

Tom,

since states are often protocol specific, I believe we are better off
with having states defined with protocol specific semantics. If you go
for generic states, then you end up with mappings of generic states to
protocol specific states, which are often non-trivial to get right and
meaningful.

/js

On Mon, Dec 31, 2018 at 12:29:34PM +, tom petch wrote:
> Many (most?) routing protocols introduce a state - up, down +- coming
> up, going down, maintenance and such like, used for interfaces, tunnels,
> adjacencies and the like.  It is a shame that there are so many
> variations on this although to some extent this reflects the differences
> in the protocols.  And some use types, others identity.
> 
> Tom Petch
> 
> 
> - Original Message -
> From: "Juergen Schoenwaelder" 
> Sent: Friday, November 30, 2018 11:56 AM
> 
> > This is already on my list (was already proposed by Balázs).
> >
> > /js
> >
> > On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> > > Balázs Lengyel  wrote:
> > > > Hello,
> > > >
> > > > In a similar manner we found multiple uses for the
> > > > ietf-netconf-acm:node-instance-identifier. We
> > > > imported nacm just to reuse this type.
> > > > Anyone else interested?
> > >
> > > Yes, this is a useful type that is not just NACM-specific.  We also
> > > use in various places.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > regards Balazs
> > > >
> > > > On 2018. 11. 29. 12:03, Robert Wilton wrote:
> > > >
> > > >  Hi Juergen,
> > > >
> > > >  YANG library currently defines the type "revision-identifer". Is
> this a typedef that should
> > > >  logically migrate to rfc6991bis?
> > > >
> > > >  Thanks,
> > > >  Rob
> > > >
> > > >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > > >
> > > >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > > >
> > > >  Hi,
> > > >
> > > >  Alex Campbell  wrote:
> > > >
> > > >  Does a percentage really need a single standard type in the first
> > > >  place? How about "units percent;"?
> > > >
> > > >  At this point, after hearing about how different modules have
> > > >  differing requirement on this type, I tend to agree.
> > > >
> > > >  +1
> > > >
> > > >  Or even "units %;"
> > > >
> > > >  Lada
> > > >
> > > >  /martin
> > > >
> > > >  
> > > >  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"
> > > >   > > >  j.schoenwael...@jacobs-university.de> 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

Re: [netmod] for a future rfc6991bis

[Acee Lindem (acee)]

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

Re: [netmod] for a future rfc6991bis

[Acee Lindem (acee)]

I’ll participate as well. I agree it should be a separate YANG module and draft 
from the geo-location advertisement protocol specifications (currently OSPF, 
IS-IS, BGP, and LISP).
Thanks,
Acee

From: netmod  on behalf of Qin Wu 
Date: Friday, November 2, 2018 at 8:16 AM
To: Juergen Schoenwaelder 
Cc: netmod 
Subject: Re: [netmod] for a future rfc6991bis

I can volunteer to do that if this helps.
发件人： Juergen Schoenwaelder
收件人： Qin Wumailto:bill...@huawei.com>>
抄送： netmodmailto:netmod@ietf.org>>
主题： Re: [netmod] for a future rfc6991bis
时间： 2018-11-02 15:23:10

It seems someone should draft an ietf-geo yang module proposal.

/js

On Fri, Nov 02, 2018 at 07:42:58AM +, Qin Wu wrote:
> Longitude is not defined in RFC8299, RFC8299 provide location parameter such 
> as city, country, country-code, postal-code, street.
> https://www.ietf.org/archive/id/draft-acee-ospf-geo-location-05.txt  seems to 
> provide a few definitions of longitude and latitude in section 2:
> https://tools.ietf.org/html/draft-seedorf-lmap-alto-02#section-6.2 provide an 
> example of longitude usage in table 1 which use different unit(i.e.,decimal 
> degree)
> See 
> https://www.rapidtables.com/convert/number/degrees-to-degrees-minutes-seconds.html
> RFC6280 provide a good taxonomy of location object.
> "
>Location Object (LO):   An object used to convey location information
>   together with Privacy Rules.  Geopriv supports both geodetic
>   location data (latitude, longitude, altitude, etc.) and civic
>   location data (street, city, state, etc.).  Either or both types
>   of location information may be present in a single LO (see the
>   considerations in [5] for LOs containing multiple locations).
>   Location Objects typically include some sort of identifier of the
>   Target.
> "
>
> -Qin
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2018年11月2日 15:07
> 收件人: Qin Wu 
> 抄送: netmod 
> 主题: Re: [netmod] for a future rfc6991bis
>
> I searched for longitute or geo in RFC 8299 and this was not a big hit.. 
> Concrete definitions will help. I do know about
> https://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-07 and that has 
> been dragging on from 2012 to 2016 within the NMRG and I think this even had 
> a life outside the NMRG before. What I am looking for is concrete (ideally 
> YANG) definitions that people have already created and that can be the basis 
> of a common standard. And of course an argument why location data is so 
> essential that it has to be in ietf-yang-types and can't be in say a module 
> ietf-geo-types.
>
> /js
>
> On Fri, Nov 02, 2018 at 03:17:21AM +, Qin Wu wrote:
> > Agree with this criteria, remember geo location proposal was discussed 
> > before by ALTO proponents in LMAP, in addition, location service is useful 
> > for L3VPN sevice placement, see example case in RFC8299 which can select 
> > appropriate PE based on location info. Acee also provided a valid use case 
> > in this e-mail thread.
> >
> > 发件人： Juergen Schoenwaelder
> > 收件人： Qin Wumailto:bill...@huawei.com>>
> > 抄送： netmodmailto:netmod@ietf.org>>
> > 主题： Re: [netmod] for a future rfc6991bis
> > 时间： 2018-11-01 20:04:15
> >
> > I think we need to find a way to limit the update to types that are
> > known (or expected) to be 'widely' needed. In other words, for every
> > proposed type, an argument should be made why this should be included
> > in RFC 6991bis.
> >
> > /js
> >
> > On Thu, Nov 01, 2018 at 11:55:25AM +, Qin Wu wrote:
> > > I am wondering if we can add longitude, latitude in DMS or decimal
> > > degree, Further we can consider to add Postal-code, Country-code
> > > like Location type.
> > >
> > > -Qin
> > > -邮件原件-
> > > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen
> > > Schoenwaelder
> > > 发送时间: 2018年10月31日 20:47
> > > 收件人: netmod@ietf.org
> > > 主题: Re: [netmod] for a future rfc6991bis
> > >
> > > Here is my list of possible additions. I might have lost some items on a 
> > > computer that meanwhile is not used anymore, I will have to dig a bit to 
> > > see what I can recover.
> > >
> > > /js
> > >
> > > On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> > > > Hi,
> > > >
> > > > another update that was discussed recently is a clarification of
> > > > the XPath context for the xpath1.0 type.
> > > >
> > > > Lada
> > > >
> > > > Kent Watsen  writes:
> > > >
> > > > > NETMOD WG,
> > > > >
> > > > > A conversation in NETCONF WG regarding the yang-push noted that
> > > > > it might be time to update RFC 6991, in particular to introduce a 
> > > > > type for time-duration.
> > > > >
> > > > >
> > > > > https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZ
> > > > > NwB-
> > > > > SYBnQ
> > > > >
> > > > > In addition, it might be good to introduce [inet?] types for RFC
> > > > > 5322 (Internet Message Format) including perhaps:
> > > > >
> > > > >   - email-address(addr-spec, per Section 

Re: [netmod] for a future rfc6991bis

[Acee Lindem (acee)]

Hi Qin,

On 11/1/18, 10:44 AM, "Qin Wu"  wrote:

That's a good use case for geo-location service. If the geo-location 
information is specified in routing protocol, I think it should also be 
specified by YANG, but need to make sure they are consistent.
For precision of longitude and latitude, why not use DMS (Degree, Minute, 
Second)? 

I'd be happy to reach consensus on this but we're going to solve it in this 
Email thread. 

Thanks,
Acee

-Qin
-邮件原件-
    发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2018年11月1日 22:18
收件人: Qin Wu ; Juergen Schoenwaelder 
; netmod@ietf.org
主题: Re: [netmod] for a future rfc6991bis

Hi Qin,

We'd tried to converge on geo-coordinates in the protocols and received and 
a rather wide range of opinions as to the precision and what was required. An 
IETF consensus is required and not everyone is going to be happy. However, I'm 
not sure where this work lies and it hasn't been a priority for me. In fact, I 
let my draft expire: 
https://www.ietf.org/archive/id/draft-acee-ospf-geo-location-05.txt. I think 
trying to adding these before this happens could delay the BIS update. 

Thanks,
Acee

On 11/1/18, 7:55 AM, "netmod on behalf of Qin Wu"  wrote:

I am wondering if we can add longitude, latitude in DMS or decimal 
degree,
Further we can consider to add
Postal-code, Country-code like Location type.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2018年10月31日 20:47
收件人: netmod@ietf.org
主题: Re: [netmod] for a future rfc6991bis

Here is my list of possible additions. I might have lost some items on 
a computer that meanwhile is not used anymore, I will have to dig a bit to see 
what I can recover.

/js

On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> another update that was discussed recently is a clarification of the 
> XPath context for the xpath1.0 type.
> 
> Lada
> 
> Kent Watsen  writes:
> 
> > NETMOD WG,
> >
> > A conversation in NETCONF WG regarding the yang-push noted that it 
> > might be time to update RFC 6991, in particular to introduce a type 
for time-duration.
> >
> >   
> > https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-
> > SYBnQ
> >
> > In addition, it might be good to introduce [inet?] types for RFC 
> > 5322 (Internet Message Format) including perhaps:
> >
> >   - email-address(addr-spec, per Section 3.4.1)
> >   - named-email-address  (name-addr, per Section 3.4)
> >
> >
> > Kent // contributor
> >
> >
> >
> > ___
> > 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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
___
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] for a future rfc6991bis

[Acee Lindem (acee)]

Hi Qin,

We'd tried to converge on geo-coordinates in the protocols and received and a 
rather wide range of opinions as to the precision and what was required. An 
IETF consensus is required and not everyone is going to be happy. However, I'm 
not sure where this work lies and it hasn't been a priority for me. In fact, I 
let my draft expire: 
https://www.ietf.org/archive/id/draft-acee-ospf-geo-location-05.txt. I think 
trying to adding these before this happens could delay the BIS update. 

Thanks,
Acee

On 11/1/18, 7:55 AM, "netmod on behalf of Qin Wu"  wrote:

I am wondering if we can add longitude, latitude in DMS or decimal degree,
Further we can consider to add
Postal-code, Country-code like Location type.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2018年10月31日 20:47
收件人: netmod@ietf.org
主题: Re: [netmod] for a future rfc6991bis

Here is my list of possible additions. I might have lost some items on a 
computer that meanwhile is not used anymore, I will have to dig a bit to see 
what I can recover.

/js

On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> another update that was discussed recently is a clarification of the 
> XPath context for the xpath1.0 type.
> 
> Lada
> 
> Kent Watsen  writes:
> 
> > NETMOD WG,
> >
> > A conversation in NETCONF WG regarding the yang-push noted that it 
> > might be time to update RFC 6991, in particular to introduce a type for 
time-duration.
> >
> >   
> > https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-
> > SYBnQ
> >
> > In addition, it might be good to introduce [inet?] types for RFC 
> > 5322 (Internet Message Format) including perhaps:
> >
> >   - email-address(addr-spec, per Section 3.4.1)
> >   - named-email-address  (name-addr, per Section 3.4)
> >
> >
> > Kent // contributor
> >
> >
> >
> > ___
> > 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

-- 
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 adoption poll for draft-clemm-netmod-nmda-diff-00

[Acee Lindem (acee)]

Support. 

On 10/1/18, 2:48 PM, "netmod on behalf of Kent Watsen" 
 wrote:

The IETF 102 in-room poll should really good support to adopt
this draft, and no objections.

This email starts an adoption poll for:

  https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00

Please indicate your support or objection to the adoption poll. 
If objecting, please state your reasons on this thread.

Kent (and Lou and 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] YANG module security considerations template - TLS reference

[Acee Lindem (acee)]

Agreed. I think we should have a couple designated experts (similar to what we 
have with IANA registries) that would have editorial authority and could field 
suggestions for updates (e.g., for example from the Security ADs).

Thanks,
Acee

On 10/1/18, 2:50 PM, "Lou Berger"  wrote:

At this point I think it's mature enough to be a yang DR or NETMOD wg thing?

Thoughts, objections?

Lou


--
On October 1, 2018 2:32:34 PM Kent Watsen  wrote:

> Benoit is the progenitor of the template.  I took it to be an "AD thing"
> has since passed to Ignas.
>
> Kent
>
>
>
> ?-Original Message-
> From: "Acee Lindem (acee)" 
> Date: Monday, October 1, 2018 at 10:25 AM
> To: Martin Bjorklund , "netmod-cha...@ietf.org" 
> , "netmod-...@ietf.org" , 
> "netmod@ietf.org" 
> Subject: Re: [netmod] YANG module security considerations template - TLS 
> reference
> Resent-From: 
> Resent-To: , , 
, 
> 
> Resent-Date: Monday, October 1, 2018 at 10:25 AM
>
> Agreed - although I'm not sure who has control over the template either.
>
> For drafts that are in-progress, IDNITs will flag this obsolete reference 
> and, for at least one of the drafts I'm an editor, I've already made the 
> update.
>
> Thanks,
> Acee
>
> On 10/1/18, 3:19 AM, "netmod on behalf of Martin Bjorklund" 
>  wrote:
>
> Hi,
>
> In their review of draft-ietf-netconf-nmda-restconf, the IESG
> suggested we update the reference to TLS from RFC 5246 to RFC 8446
> (which obsoletes 5246).
>
> This update needs to be done to the template available at
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_ops_wiki_yang-2Dsecurity-2Dguidelines=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=54lt0_rCJTvXEIWmFXsdUNDbzJIkrJ86K-IveL1QoG4=9uZWNJN6weNKKk7ABnZ-yFVkwdZxZzQOSm9bSXwT1SQ=
>
> (it is not quite clear who is repsonsible for this template; maybe
> that should be clarified on the page)
>
>
> /martin
>
> ___
> netmod mailing list
> netmod@ietf.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=54lt0_rCJTvXEIWmFXsdUNDbzJIkrJ86K-IveL1QoG4=QhZGZPVsGhr3-uPQZRPyHFcBYz59K2QZxenbb7Ly7L8=
>
>
>
> ___
> 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 module security considerations template - TLS reference

[Acee Lindem (acee)]

Agreed - although I'm not sure who has control over the template either. 

For drafts that are in-progress, IDNITs will flag this obsolete reference and, 
for at least one of the drafts I'm an editor, I've already made the update.

Thanks,
Acee 

On 10/1/18, 3:19 AM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Hi,

In their review of draft-ietf-netconf-nmda-restconf, the IESG
suggested we update the reference to TLS from RFC 5246 to RFC 8446
(which obsoletes 5246).

This update needs to be done to the template available at
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

(it is not quite clear who is repsonsible for this template; maybe
that should be clarified on the page)


/martin

___
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 adoption poll draft-ietf-netmod-module-tags-02

[Acee Lindem (acee)]

Yes/support
Thanks,
Acee

On 9/26/18, 10:41 AM, "netmod on behalf of joel jaeggli" 
 wrote:

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a 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.



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

Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

[Acee Lindem (acee)]

Mirja, 

See inline. 

On 9/25/18, 6:29 PM, "netmod on behalf of Mirja Kuehlewind (IETF)" 
 wrote:

Hi Mahesh, hi Eliot,

please see below.

> Am 25.09.2018 um 22:25 schrieb Eliot Lear :
> 
> Just on this point:
> 
> On 25.09.18 20:35, Mahesh Jethanandani wrote:
>>> That’s do bad. However, the document must at least say that it’s scope 
is

(sorry for the type… I meant to say „too bad“.)

>>> restricted to TCP and UDP only and it would also be nice to reason why 
that restriction is and what would need to be done to extend it in future.
>> 
>> To the contrary. The model is not restricted to TCP and UDP. In Section 
2, the document states that:
>> 
>>ACL implementations in every device may vary greatly in terms of the
>>filter constructs and actions that they support.  Therefore this
>>draft proposes a model that can be augmented by standard extensions
>>and vendor proprietary models.
>> 
>> 
Yes, ACL implementations differ, however, the protocol spec for SCTP and 
DCCP don’t have different implementation; their are mostly fixed. 
Unfortunately, firewalls often just block any other traffic than TCP and UDP, 
and restricting such a model only to those protocols will definitely not help 
the situation.

>> 
>> It is a different matter that it has chosen not to support SCTP and 
DCCP. That is because implementations today have not felt the market need to 
add support for those protocols. But that does not prevent anyone from adding 
support for them.

If your YANG model does not support long-existent and well-specified 
protocols, that doesn’t make it any easier to add support for these protocols 
to your firewall.

>> 
>> As far as an example for how the model can be extended in the future, 
see Appendix A - Extending ACL model examples.
> 
> It's important to not try to boil the ocean, and this model is already 
boiling a rather large river.  There's room for someone else to do more work.  
I know I did ;-)

I would think that adding another well-specified protocols is actually only 
a limited effort.

How many YANG models have you authored? This would be a great opportunity. 

   However, I don’t want to enforce a lot of additional work if people are not 
interested in that. What I still would like to see in the document is to make 
clear that these protocols have not just beennot considered but some 
reasoning why only the currently supported protocols have been selected (in 
order to make the reader aware that this is not a full set).

I would think pointing out that these protocols are out of scope would suffice. 
However, I'll leave that to the author.

Thanks,
Acee


Mirja


> 
> Eliot

___
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] xpath for must statements

[Acee Lindem (acee)]

Hi William, 

On 8/8/18, 4:41 AM, "netmod on behalf of Ivory, William" 
 wrote:

On 07/08/18 23:01, Acee Lindem (acee) wrote:
Is it possible to indicate that choice statement must be specified in a 
YANG 1.1 “must” clause w/o specifying every case? Similarly, it is there a way 
specify that a container cannot be empty in “must” clause?
Thanks,
Acee

[to list this time ...]

For the second, just check the container has children:

must "/*";

I'll try this. 

Thanks - it seems it should work as long as the container only contain leaves 
and presence containers. 
Acee


Regards,

William

___
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] xpath for must statements

[Acee Lindem (acee)]

Thanks Martin - see inline. 

On 8/8/18, 3:43 AM, "Martin Bjorklund"  wrote:

Hi,

"Acee Lindem \(acee\)"  wrote:
> Is it possible to indicate that choice statement must be specified
> in a YANG 1.1 “must” clause w/o specifying every case?

Do you mean that you to ensure that a case is always configured?  If
so, mark the choice as "mandatory true".  It can't be done with an
XPath expression.

It's not that easy since at the least the choice or another leaf must be 
specified. I found that the choice and case identifiers are not part of the 
Xpath. Even after rereading some sections of RFC7950, this wasn't intuitive.

Thanks,
Acee 


/martin



> Similarly, it is there a way specify that a container cannot be empty in 
“must” clause?
> Thanks,
> Acee


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

[netmod] xpath for must statements

[Acee Lindem (acee)]

Is it possible to indicate that choice statement must be specified in a YANG 
1.1 “must” clause w/o specifying every case? Similarly, it is there a way 
specify that a container cannot be empty in “must” clause?
Thanks,
Acee
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6087bis - Security Considerations template

[Acee Lindem (acee)]

Hi Martin, 

On 8/6/18, 2:51 PM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Hi,

Ladislav Lhotka  wrote:
> Hi,
> 
> Shawn Emery reviewed draft-ietf-netmod-schema-mount-10 and made this
> editorial comment:
> 
> OLD:
> 
> These are the subtrees and data nodes and their sensitivity/vulnerability:
> 
> NEW:
> 
> The following should be considered for subtrees/data nodes and their
> corresponding sensitivity/vulnerability:
> 
> However, the OLD fomulation comes from RFC 6087, so perhaps this change
> should be applied in draft-ietf-netmod-rfc6087bis in the first
> place. The NEW formulation indeed looks better to me.

What is the WG's opinion on this proposed text change?  6087bis is in
AUTH48 so if it needs to be changed it must happen now.


Most of the existing YANG model security considerations are written a list of 
data nodes/subtrees and their corresponding sensitivity/vulnerability. So, if 
the change is accepted, new drafts would need to be written as a list of 
sensitivities/vulnerabilities with the data nodes and subtrees to which they 
apply. 

Thanks,
Acee


Of course, we can update
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines even when
6087bis has been published.

If we don't want to update the template, I don't think we should
update the schema mount draft either.


/martin




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


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

Re: [netmod] "iana" in yang modules' name/namespace/prefix

[Acee Lindem (acee)]

Hi Benoit, et al, 
I couldn't agree more. The IETF has much more exigent issues with respect to 
YANG models and the attendant protocol infrastructure than whether IANA might 
go away in the future. 
Thanks,
Acee 

On 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise" 
 wrote:

Martin,

I'm wonder whether this is really an important optimization, worth 
changing now, in the hypothetical case that IANA is not called IANA any 
longer in the future?
Right now, "iana" n the YANG module name correctly states what this is about
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
 => "maintained by IANA"
I agree with Jürgen that documenting this in 6087bis is the right way 
forward.

Regards, Benoit.
> Hello
>
> As part of a recent IESG review (of draft-bfd-yang) a point came up on 
> the use of "iana" in yang modules' name/namespace/prefix.
> This is typically used in the case where the module refers to an IANA 
> maintained registry. However, the point raised was that the name of 
> the registry operator might not always be IANA, and that using that 
> name might not put modules on the most stable deployment footing under 
> all possible circumstances.
>
> On top of that, as far as I can tell, the use of "iana" is an 
> undocumented convention.
>
> So, I wanted to collect views:
> on whether a convention should be documented,
> and, with regards to the point raised in IESG, on whether that keyword 
> should be changed going forward. In that context, what about "reg" 
> (for registry) or "regop" (for registry operator)? Other proposals are 
> welcome.
>
> Thanks
> -m
>
> ___
> 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] "iana" in yang modules' name/namespace/prefix

[Acee Lindem (acee)]

Hi Martin, 
I would prefer not using "reg" since it will always be an abbreviation for a 
machine language register to me. I'd favor using "registry" in the module name 
and the more cryptic "reg" in the module prefix. 
Thanks,
Acee 

On 7/20/18, 9:46 AM, "netmod on behalf of Martin Vigoureux" 
 wrote:

Hello

As part of a recent IESG review (of draft-bfd-yang) a point came up on 
the use of "iana" in yang modules' name/namespace/prefix.
This is typically used in the case where the module refers to an IANA 
maintained registry. However, the point raised was that the name of the 
registry operator might not always be IANA, and that using that name 
might not put modules on the most stable deployment footing under all 
possible circumstances.

On top of that, as far as I can tell, the use of "iana" is an 
undocumented convention.

So, I wanted to collect views:
on whether a convention should be documented,
and, with regards to the point raised in IESG, on whether that keyword 
should be changed going forward. In that context, what about "reg" (for 
registry) or "regop" (for registry operator)? Other proposals are welcome.

Thanks
-m

___
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 identities and identityref's

[Acee Lindem (acee)]

On 5/3/18, 4:23 PM, "Martin Bjorklund" <m...@tail-f.com> wrote:

    "Acee Lindem (acee)" <a...@cisco.com> wrote:
> 
> 
> On 5/3/18, 2:40 PM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
> 
    > On Thu, 2018-05-03 at 18:00 +, Acee Lindem (acee) wrote:
> > Hi Lada, 
> > 
> > So you have a base identify of foo-type and subordinates of
> > foo-type-1, foo-
> > type-2, ... foo-type-9. You have a data leaf that type identityref
> > foo-type
> > but the actual instantiation is not one of the known foo-types. 
Should
> > a foo-
> > type-unknown be defined to return for this case or should one just
> > return foo-
> > type? 
> 
> Hmm, the actual instantiation looks like invalid data. If the leaf is
> an
> identityref with "foo-type" as its base, then permitted values are
> exactly those
> "foo-type-[1-9]".
> 
> The whole reason to use identities rather than enums is to allow for
> incremental extension.

Yes.

> With routing protocols, it is possible if not
> likely to have an instantiation of a data leaf that is unknown. So, we
> absolutely need to handle this case.

But the instrumentation code that fills in the value (assuming it is
config false) knows what it is, right?

No - there are multiple devices in the network and they could have different 
level of support. For example, OSPF will accept OSPF Link State Advertisement 
(LSA) TLV types that it doesn't yet understand. The OSPF Link State Database 
can be retrieved via a YANG model. This seems like a pretty basic use case to 
me. 

  Then it might be better to
have the vendor define a proprietaty identity that is derived from
foo-type, and let the instrumentation code use that identity.

Or define the foo-type-unknown in the model since this is such a common case.  

Thanks,
Acee 


/martin

> Acee 
> 
> If the server supports a particular type, then I would expect it to
> implement a
> module where the identity corresponding to that type is defined.
> 
> Lada 
> 
> >  
> > 
> > Thanks,
> > Acee
> > 
> > On 5/3/18, 1:49 PM, "netmod on behalf of Ladislav Lhotka"
> > <netmod-bounces@iet
> > f.org on behalf of lho...@nic.cz> wrote:
> > 
> > Hi Acee,
> > 
> > I am not sure what you mean by unknown identities. In general, 
the
> > identity used
> > as the base of an identityref (or in Xpath functions
> > derived-from/derived-
> > from-
> >     or-self) should be the most general identity that can match at 
the
> > given
> > place.
> > 
> > Do you have any example illustrating your case?
> > 
> > Lada
> > 
> > 
> > On Thu, 2018-05-03 at 17:30 +, Acee Lindem (acee) wrote:
> > > Let’s say one define a base identity with a hierarchy of
> > > identifyref’s
> > using
> > > it. This will allow for augmentation in future models. Should 
one
> > > also
> > define
> > > an identityref for the class of unknown identities? Or, 
should one
> > simply
> > > return the lowest parent in the hierarchy matching the value? 
Many
> > times, this
> > > would be the base identity.
> > >  
> > > Thanks,
> > > Acee
> > > ___
> > > 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
> > 
> > 
> -- 
> 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] YANG identities and identityref's

[Acee Lindem (acee)]

Hi Lada, 

So you have a base identify of foo-type and subordinates of foo-type-1, 
foo-type-2, ... foo-type-9. You have a data leaf that type identityref foo-type 
but the actual instantiation is not one of the known foo-types. Should a 
foo-type-unknown be defined to return for this case or should one just return 
foo-type?  

Thanks,
Acee

On 5/3/18, 1:49 PM, "netmod on behalf of Ladislav Lhotka" 
<netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:

Hi Acee,

I am not sure what you mean by unknown identities. In general, the identity 
used
as the base of an identityref (or in Xpath functions 
derived-from/derived-from-
or-self) should be the most general identity that can match at the given 
place.

Do you have any example illustrating your case?

Lada


On Thu, 2018-05-03 at 17:30 +0000, Acee Lindem (acee) wrote:
> Let’s say one define a base identity with a hierarchy of identifyref’s 
using
> it. This will allow for augmentation in future models. Should one also 
define
> an identityref for the class of unknown identities? Or, should one simply
> return the lowest parent in the hierarchy matching the value? Many times, 
this
> would be the base identity.
>  
> Thanks,
> Acee
> ___
> 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

[netmod] YANG identities and identityref's

[Acee Lindem (acee)]

Let’s say one define a base identity with a hierarchy of identifyref’s using 
it. This will allow for augmentation in future models. Should one also define 
an identityref for the class of unknown identities? Or, should one simply 
return the lowest parent in the hierarchy matching the value? Many times, this 
would be the base identity.

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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Acee Lindem (acee)]

From: netmod  on behalf of "Robert Wilton -X (rwilton 
- ENSOFT LIMITED at Cisco)" 
Date: Friday, March 9, 2018 at 9:59 AM
To: Adam Roach , Andy Bierman 
Cc: NetMod WG Chairs , 
"draft-ietf-netmod-rfc6087...@ietf.org" 
, The IESG , NetMod WG 

Subject: Re: [netmod] Adam Roach's No Objection on 
draft-ietf-netmod-rfc6087bis-18: (with COMMENT)


Hi Adam,

On 08/03/2018 23:55, Adam Roach wrote:
Thanks for your quick response! I have some additional comments inline.



Clearly, the items that have already been published can't be changed, but it 
seems like there is room for guidance about whether to optimize for simple 
regexes, or for more rigorous ones.
I agree with your general sentiment.  In fact I had a long protracted 
discussion on this point on the Netmod WG alias.

Sometimes pattern statements can be both correct and also concise and readable. 
 This is the easy case.

But for other regular expressions (e.g. route-target in rfc8294) there is a 
clear choice whether to make the regex as precise as possible (minimizing false 
values), or to make it concise and hopefully readable/verifiable but allowing 
for more false values.

My personal preference is for a simpler, but less precise regex over a more 
precise, but hard to visually verify, regex.  E.g. I'm not a fan of using 
regular expressions to limit the range of numerical values.  I know that 
validating regular expression matches is computationally expensive, so I wonder 
if implementations will end up replacing these larger regular expressions with 
custom written verification code that is more performant.  But, as I recall, I 
was in the rough on this issue.

If the consensus is that they should be as accurate as is feasible then I think 
that it would be helpful if the guidelines state this as a goal.  This would 
seem to ensure consistency in the YANG models that are being standardized.

As the editor of RFC 8294, I can confirm that we did not reach consensus on 
whether to use easily understandable regular expressions versus regular 
expressions that precisely validate the input string. During the protracted 
Working Group last call for this document, there were strong proponents of both 
lines of thinking. Given that we had started with the more complex precise 
regular expressions, that is what was retained (e.g., for BGP route-targets).

 typedef route-target {
   type string {
 pattern
   '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
 + '6[0-4][0-9]{3}|'
 + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|'
 + '42949672[0-8][0-9]|'
 + '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
 + '42949[0-5][0-9]{4}|'
 + '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
 + '42[0-8][0-9]{7}|4[01][0-9]{8}|'
 + '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|'
 + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
 + '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
 + '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
 + '655[0-2][0-9]|'
 + '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
 + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
 + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
 + '4294967[01][0-9]{2}|'
 + '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
 + '4294[0-8][0-9]{5}|'
 + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
 + '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):'
 + '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
 + '6[0-4][0-9]{3}|'
 + '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
 + '(6(:[a-fA-F0-9]{2}){6})|'
 + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
 + '[0-9a-fA-F]{1,12})';
   }

   description
 "A Route Target is an 8-octet BGP extended community
  initially identifying a set of sites in a BGP VPN
  (RFC 4364).  However, it has since taken on a more general
  role in BGP route filtering.  A Route Target consists of two
  or three fields: a 2-octet Type field, an administrator
  field, and, optionally, an assigned number field.

  According to the data formats for types 0, 1, 2, and 6 as
  defined in RFC 4360, RFC 5668, and RFC 7432, the encoding
  pattern is defined as:

  0:2-octet-asn:4-octet-number
  1:4-octet-ipv4addr:2-octet-number
  2:4-octet-asn:2-octet-number
  6:6-octet-mac-address

  Additionally, a generic pattern is defined for future
  Route Target types:

  2-octet-other-hex-number:6-octet-hex-number

  Some valid examples are 0:100:100, 1:1.1.1.1:100,
  2:1234567890:203, and 6:26:00:08:92:78:00.";
   reference
 "RFC 4360: BGP Extended Communities Attribute.
   

Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Acee Lindem (acee)]

I support netmod WG adoption.
Thanks,
Acee

From: netmod  on behalf of joel jaeggli 

Date: Tuesday, February 6, 2018 at 6:58 PM
To: "netmod@ietf.org" 
Subject: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: 
draft-rtgyangdt-netmod-module-tags-02


Sorry, Feb 20th is the end date for the adoption call.

regards

joel

On 2/6/18 3:47 PM, joel jaeggli wrote:

Hi,

This is the start of a *two* week poll on making 
draft-rtgyangdt-netmod-module-tags-02 a working group document.

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

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.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-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] I-D Action: draft-ietf-netmod-rfc8022bis-11.txt

[Acee Lindem (acee)]

Just a small fix to the RIP YANG example based on comments from Francis Dupont. 
Thanks,
Acee 

On 1/26/18, 8:06 AM, "netmod on behalf of 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 Network Modeling WG of the IETF.

Title   : A YANG Data Model for Routing Management (NMDA 
Version)
Authors : Ladislav Lhotka
  Acee Lindem
  Yingzhen Qu
Filename: draft-ietf-netmod-rfc8022bis-11.txt
Pages   : 77
Date: 2018-01-26

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-11
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-11


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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-10.txt

[Acee Lindem (acee)]

This version addresses Ben Campbell's and Suresh Krishnan's IESG Telechat 
comments. 
Thanks,
Acee 

On 1/25/18, 12:07 PM, "netmod on behalf of 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 Network Modeling WG of the IETF.

Title   : A YANG Data Model for Routing Management (NMDA 
Version)
Authors : Ladislav Lhotka
  Acee Lindem
  Yingzhen Qu
Filename: draft-ietf-netmod-rfc8022bis-10.txt
Pages   : 77
Date: 2018-01-25

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-10
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-10


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

Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)

[Acee Lindem (acee)]

Hi Suresh, 

Thanks for the review - see inline. 

On 1/24/18, 10:43 AM, "Suresh Krishnan"  wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc8022bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/



--
COMMENT:
--

* Lots of places in the document where NMDA is misspelled as NDMA. Please 
fix.

I'm hardwired to type "N-D" - you can take the boy out of North Dakota but you 
can't the North Dakota out of the boy... I've fixed all these. 



* Section 9.1.

The ranges for AdvDefaultLifetime and MaxRtrAdvInterval have been changed by
RFC-to-be-8319 to update the values specified in RFC4861.  Please change 
these
ranges to the new values.

OLD:

leaf max-rtr-adv-interval {
   type uint16 {
 range "4..1800";
   }

NEW:

leaf max-rtr-adv-interval {
   type uint16 {
 range "4..65535";
   }

OLD:

 leaf default-lifetime {
   type uint16 {
 range "0..9000";
   }

NEW:
 leaf default-lifetime {
   type uint16 {
 range "0..65535";
   }

Good point, these changes will be in th -10 version. 

Thanks,
Acee


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

Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-rfc8022bis-09: (with COMMENT)

[Acee Lindem (acee)]

Hi Ben, 

On 1/23/18, 9:56 PM, "Ben Campbell"  wrote:

Ben Campbell has entered the following ballot position for
draft-ietf-netmod-rfc8022bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/



--
COMMENT:
--

There are a few instances of 2119 keywords in lower case. Please consider 
using
the boilerplate from RFC 8174.

This sounds familiar ;^). I'll update the section and add RFC 8174 as a 
normative reference. 

Thanks,
Acee 





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

Re: [netmod] Genart telechat review of draft-ietf-netmod-rfc8022bis-06

[Acee Lindem (acee)]

Thanks Francis!
Acee

On 1/23/18, 5:55 PM, "Francis Dupont"  wrote:

Reviewer: Francis Dupont
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-netmod-rfc8022bis-??
Reviewer: Francis Dupont
Review Date: 2018-01-23
IETF LC End Date: 2018-01-15
IESG Telechat date: 2018-01-25

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: I'll send another message tomorrow with a few 
comments.




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

Re: [netmod] schema mount and YANG library

[Acee Lindem (acee)]

It was WG Last Call’ed: 
https://mailarchive.ietf.org/arch/msg/netmod/csUvs6408En0yY-vapyU3IFcJqQ

And it was closed: 
https://mailarchive.ietf.org/arch/msg/netmod/gbXE4Le1I_3Y5oaNnpjYoZZZ4lw

However, it may not have ever completed.

Thanks,
Acee 

On 1/22/18, 11:45 AM, "Juergen Schoenwaelder" 
<j.schoenwael...@jacobs-university.de> wrote:

Acee,

the documents that have already finished WG Last Call have a normative
reference on schema mount, which has not yet finished WG Last Call as
far as I recall. I think the RFC editor does not publish a document
with a missing normative reference. I continue to believe that the
time difference between doing the right thing and doing something
faster using definition we are in the process to deprecate is really
small. But of course, I may be entirely wrong.

/js

On Mon, Jan 22, 2018 at 04:18:15PM +0000, Acee Lindem (acee) wrote:
> Hi Lada, 
> 
> My primary concern is that the YANG Schema Mount delay will not only hold 
the NI/LNE but all the models that are dependent on them (e.g., L2VPN and 
L3VPN). This is for a document that has already finished WG Last Call. 
Additionally, your estimate for the size of the change and time to reach 
standardization is based on there being immediate consensus on the changes. 
This is probably overly optimistic given there was discussion on the proposed 
YANG Library BIS changes. I’d vote to publish the existing draft. 
> 
> In any case, being able to see the proposed changes ASAP is critical. 
> 
> Thanks,
> Acee
> 
> On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka" 
<netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
> 
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes:
> 
> > On Fri, Jan 19, 2018 at 06:05:15PM +, Robert Wilton wrote:
> >> 
> >> Hence, for me, I see the choice as:
> >> 1) do we publish the existing model now (perhaps also mark the 
draft as
> >> experimental) followed by an updated draft with the NMDA 
compatible module?
> >> 2) do we publish both models in a single draft (e.g. with the 
existing model
> >> in an appendix)?
> >> 3) do we only publish a single version of the draft with an NMDA 
compliant
> >> solution.
> >>
> >
> > I think the situation is as follows (likely obvious but it may help 
to
> > make sure we are all on the same page):
> >
> > - the NI and LNE models have a normative reference to
> >   I-D.ietf-netmod-schema-mount (and this makes sense since there are
> >   MUST sentences in the I-D)
> >
> > - I-D.ietf-netmod-schema-mount (last updated in October) has 
normative
> >   references to RFC 7895 (old YANG library)
> >
> > - RFC 7895 does not work with NMDA, NMDA work on a YANG library 
update
> >   replacing RFC 7895
> >
> > So the YANG library update is gating the schema mount update which 
is
> > gating the publication of the NI and LNE models.
> >
> > A proper solution would be to prioritize work on the YANG library
> > update and the schema mount update. I assume that the next revision 
of
> > the YANG library update (say end of January) is ready for WG last 
call
> > and perhaps the schema mount authors can take an effort to get that
> > document there as well, say beginning of February.
> 
> I completely agree.
> 
> Lada
> 
> >
> > /js
> >
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany
> > Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
> >
> > ___
> > 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
> 
> 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>


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

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

[Acee Lindem (acee)]

Hi Sonal,

From: netmod > on 
behalf of Sonal Agarwal >
Date: Wednesday, January 17, 2018 at 7:25 PM
To: Kent Watsen >
Cc: "netmod@ietf.org" 
>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15

Hi Kent,

The last remaining open issue is about adding containers for addresses (source, 
destination) and ports (source, destination). A user has the choice to use the 
container or leaf for address (source/dest) and port (source/dest).  With this, 
the user can use the Yang model to configure scale ACL's.

Is this is the motivation for doing it two ways? I’d think that aggregation of 
common match criteria for scale could be better done programmatically than 
through prudent configuration.

Thanks,
Acee

I did some preliminary work on this in August/September last year, but ran out 
of time to explore this fully as I had to upload my other changes by particular 
dates.

The non implementation of this does not detract from the usability of the ACL 
model.

Closing the issue to completion will require me to revisit and implement the 
yang solution for container support in the model.

Thanks,
Sonal.


On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen 
> wrote:

H Mahesh,

>> - There is an open issue in the document (section 8) - are we going
>>  to resolve that during WG last call or is this a leftover?
>
> This will be resolved in the next version of the module. It is
> documented under Issues tab in GitHub. Should we remove it from
> the draft?

Most of Juergen's comments are editorial in nature and can truly be handled as 
part of the LC process, but this open issue has me worried, as it may result in 
a significant technical change.

What will it take to close this open issue?  Is it just a matter of the getting 
the WG to agree that it's not an issue, or do we already know that it is a real 
issue and only the solution is pending?

Thanks,
Kent




___
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] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams

[Acee Lindem (acee)]

Hi Rob, 

On 1/15/18, 10:07 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>Hi Martin,
>
>All OK with me except where I have further comments/questions inline
>below:
>
>On 15/01/2018 14:39, Martin Bjorklund wrote:
>> Hi,
>>
>> Thanks for the review!  Comments inline.
>>
>> Robert Wilton  wrote:
>>> Hi Lou, Martin
>>>
>>> I've done a quick review of draft -04.
>>>
>>> It looks well written to me.
>>>
>>> I have a spotted a few minor nits/questions.
>>>
>>> Section 1:
>>>
>>> (i) "Such diagrams are commonly used to provided " => "Such diagrams
>>> are used to provide"?
>> Ok.
>>
>>> (ii) "This document provides the syntax used in YANG Tree Diagrams."
>>> => "This document describes the syntax used in YANG Tree Diagrams", or
>>> if not "describes", perhaps "specifies"?
>> I changed to "describes".
>>
>>> (iii) "common practice is include" => "common practice is to include"
>> Ok.
>>
>>> Section 2:
>>> (iv) Are the top level data nodes really offset by 4 spaces, or should
>>> this be 2 spaces?  The example in section 2, and section 4 seem to
>>> differ here.  The submodule example in Sec 2.1 looks like it is using
>>> 2 spaces.
>> It should be 4 spaces.  I fixed the example in 2.1.
>Hum, OK.  Is this the right choice?
>  - It means that the tree is indented 2 spaces further than everything
>else (e.g. groupings, augments, etc).
>  - YANG modules in RFC's already struggle with line length anyway,
>hence wouldn't the use of 2 spaces give the model a bit more space.
>
>I also think that it would be good to check the indent of all the tree
>diagram snippets in the doc, it looks like they may be using somewhat
>varying levels of indents (between 2 and 6 spaces).

I agree - it is already hard to fit the tree diagrams into RFCs.

Thanks,
Acee 
>
>
>>
>>> (v) "is prefaces with" => "is prefaced with"
>> Ok.
>>
>>> (vi) Section 2.2, should there be an example of an unexpanded uses
>>> statement?  I was wondering if this section was under specified?
>> I have added:
>>
>> For example, the following diagram shows the "tls-transport"
>>grouping
>> from [RFC7407] unexpanded:
>>
>> +--rw tls
>>+---u tls-transport
>>
>> If the grouping is expanded, it could be printed as:
>>
>> +--rw tls
>>+--rw port? inet:port-number
>>+--rw client-fingerprint?   x509c2n:tls-fingerprint
>>+--rw server-fingerprint?   x509c2n:tls-fingerprint
>>+--rw server-identity?  snmp:admin-string
>Yes, looks good.
>
>>
>>> Section 2.6:
>>> (vii) "If the node is augmented into the tree from another module, its
>>> name is printed as :."  Does there need to be a
>>> clarification that the prefix name used is the one used by the
>>> module's import statement?  Or does it use the prefix statement from
>>> the imported modules instead (I know that these should normally be the
>>> same, but this is not guaranteed).
>> Since this is used when a node is augmented *into* the main tree, it
>> can't be the prefix in import, since the augmenting module is not
>> imported from the augmented module.  I did:
>But the YANG module must import the module that it is augmenting. If a
>local import prefix is used in the actual YANG module then it would be
>slightly harder to relate the tree output back to local import prefixes
>used in the YANG module.
>
>>
>> OLD:
>>
>>If the node is augmented into the tree from another module,
>>its name is printed as :.
>>
>> NEW:
>>
>>If the node is augmented into the tree from another module,
>>its name is printed as :, where  is the
>>prefix defined in the module where the node is defined.
>This is OK with me, but there is still a potential for a prefix
>namespace clash (since prefixes are not guaranteed to be unique).
>
>An alternative solution would be for the YANG tree diagram to list (at
>the beginning or the end of the diagram) the mappings from prefix ->
>module name used.  This has the bonus that it also explicitly lists the
>YANG modules that are being augmented, but conversely, this might end up
>just adding unnecessary noise to a diagram that should be short and
>simple ...
>
>A second alternative would be to add some vague text to state that the
>prefix to module mapping should be explicitly listed in any cases where
>the prefix name alone is not obvious.
>
>Thanks,
>Rob
>
>
>>
>>> Section 3.2.
>>> (viii) It would be slightly easier to read if there wasn't a linebreak
>>> between "--" and "tree-print-groupings", not sure if that is feasible
>>> to force this.
>> I don't think I can enforce this, but I'll look into it.  If nothing
>> else, the RFC editor will fix this.
>>
>>
>> /martin
>>
>>
>>> Thanks,
>>> Rob
>>>
>>> On 10/01/2018 16:16, joel jaeggli wrote:
 Just a reminder given the date that this was posted. This last call is
 expected to complete Monday 

Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Acee Lindem (acee)]

Hi Jon,

From: netmod > on 
behalf of Jon Shallow 
>
Date: Monday, January 8, 2018 at 10:47 AM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
>, 
"netmod@ietf.org" 
>, "Einar Nilsen-Nygaard (einarnn)" 
>, 'Mahesh Jethanandani' 
>
Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"

Hi Robert,

A good set of points.

My particular use case (hence raising the question) is defining a YANG model 
where there are multiple appliances and where ACLs are defined for each 
appliance, but there is the likelihood of the different appliances using the 
same “acl-name”, but the contents of “acl-name” are different.  Having a 
grouping (using import-by-revision) would help me considerably here.

I guess I don’t see the use case. Wouldn’t you have multiple network devices 
for multiple network devices? Or at least separate LNEs?  
https://www.ietf.org/id/draft-ietf-rtgwg-lne-model-05.txt

Thanks,
Acee

Regards

Jon

From: Robert Wilton [mailto: rwil...@cisco.com]
Sent: 08 January 2018 15:31
To: Einar Nilsen-Nygaard (einarnn); Jon Shallow; Mahesh Jethanandani
Cc: netmod@ietf.org
Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"


Hi Einar, Jon, Mahesh,

My gut instinct is that making this a grouping might not be a good idea:

1) If somebody updates the core ACL model, will then need to check that anyone 
using it should be similarly updated (unless they use import-by-revision).

2) Does it make sense to define ACLs in separate places.  Would like be more 
simple if ACLs were defined in a central place and then just referenced by 
other protocols as required.
3) I think that groupings are probably overused and I think that they can 
detract from the readability of the model.  (I regard the OpenConfig YANG 
models as an extreme example of this, where it is necessary to compile the 
modules together to figure out where everything fits together).

Having said that, I don't think that this issue is important enough to have a 
long discussion about ...

Thanks,
Rob

On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:
Since this is a 7-line change, I see no harm in it if no-one objects? Mahesh 
has the token for rolling in updates discussed just prior to the end of 2017.

Here’s a possible diff:

$ git diff -b
diff --git a/src/yang/ietf-access-control-list.yang 
b/src/yang/ietf-access-control-list.yang
index 4d698c9..b1a173f 100644
--- a/src/yang/ietf-access-control-list.yang
+++ b/src/yang/ietf-access-control-list.yang
@@ -402,6 +402,10 @@ module ietf-access-control-list {
   /*
* Configuration data nodes
*/
+  grouping access-lists-top {
+description
+  "Grouping to allow reuse of access lists container elsewhere.";
+
 container access-lists {
   description
 "This is a top level container for Access Control Lists.
@@ -576,6 +580,9 @@ module ietf-access-control-list {
 }
   }
 }
+  }
+  uses access-lists-top;
+
   augment "/if:interfaces/if:interface" {
 description
   "Augment interfaces to allow ACLs to be associated in either the

Cheers,

Einar



On 8 Jan 2018, at 10:53, Jon Shallow 
> wrote:

Hi There,

I appreciate that this is late to the table, but is it possible to set up 
“access-lists” as a “grouping” in the YANG data model so that “access-lists” 
can be included by “uses” in a higher level YANG data model?

I have raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues

Regards

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