Re: [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: lsr@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: [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 +, 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 

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

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

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

[Jürgen Schönwälder]

On Tue, Apr 05, 2022 at 01:48:25PM +, 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.

/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 

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

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

[Acee Lindem (acee)]

Hi Chris, 

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?

I agree and sent an Email to the authors of RFC 9127 BIS which is in the IESG 
right now. 

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. :)

This is the way it should be fixed, irrespective YANG backward compatibility. 
It is a bug and it ought to be fixed in RFC 6991 BIS. No products that I know 
of allow a zone via the textual convention in IP address configuration. This is 
just wrong... 

Thanks,
Acee

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: lsr@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.

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

[Christian Hopps]

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

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" > behalf of ie...@btconnect.com> 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: lsr@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

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

[Christian Hopps]

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"  behalf of ie...@btconnect.com> 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: lsr@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
>Lsr@ietf.org
>https://www.ietf.org/mailman/listinfo/lsr
> 
>___
>Lsr mailing list
>Lsr@ietf.org
>https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [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: lsr@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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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


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

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

[tom petch]

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: lsr@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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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

Re: [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: lsr@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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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

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

[tom petch]

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: lsr@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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

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

[internet-drafts]

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr