Hi Chris (as WG member),
On 4/5/22, 10:47 AM, "Christian Hopps" <[email protected]> wrote:
> On Apr 5, 2022, at 09:48, Acee Lindem (acee) <[email protected]> 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" <[email protected]> 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)
<[email protected]> 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" <[email protected]> wrote:
>>
>> From: Acee Lindem (acee) <[email protected]>
>> 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.
>>
>> <tp>
>>
>> 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" <[email protected]
on behalf of [email protected]> 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 <[email protected]> on behalf of
[email protected] <[email protected]>
>> Sent: 07 March 2022 03:14
>> To: [email protected]
>> Cc: [email protected]
>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> _______________________________________________
>> Lsr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
