Hi -
On 2022-04-07 11:31 AM, Kent Watsen wrote:
Hi Randy,
That's a reasonable rationale, and might even make a good CLR if
adopted from the very beginning, but given the ability of model
designers to read too much (or too little) into names,
perhaps one might consider the possibility of elimin
Hi -
Let me get this straight. WG A standardized types X and Y years ago,
and support for these has presumably been implemented in some number
of tools, which in turn have been used to develop some unknowable
number of products, whose deployment is even more unknowable.
WG B comes along, and wa
Hi Randy,
> That's a reasonable rationale, and might even make a good CLR if
> adopted from the very beginning, but given the ability of model
> designers to read too much (or too little) into names,
> perhaps one might consider the possibility of eliminating this
> particular source of confusion
Hi -
On 2022-04-07 12:13 AM, Jürgen Schönwälder wrote:
...
given recent discussions around ip addresses, I am not sure about the
consensus and perhaps we should consider to name the new date and time
types differently, e.g.
date -> date-with-zone
date-no-zone -> date
time -> time-with-
Given that you are asking for an incompatible change to an existing
module, the shoe would seem to be on the other foot.
If you could show it was necessary to make such an incompatible change,
then there would be a difficult argument to be had. But you simply have
not shown it. (And showing
Jürgen,
On 4/7/22, 12:08 PM, "Jürgen Schönwälder"
wrote:
On Thu, Apr 07, 2022 at 02:35:03PM +, 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 usin
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
On Thu, Apr 7, 2022 at 10:01 AM 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
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 t
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
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 doi
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 zo
Balazs,
This thread is becoming a bit unwieldy, so I will make my comment here on top.
> · The potential NBC issue behind this principle: If the
> "resolve-system" parameter is not given by the client, the server MUST NOT
> modify in any way not specified by the client.
> BALAZS2: I ve
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 behaviou
On Thu, Apr 07, 2022 at 02:35:03PM +, 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
On Thu, Apr 07, 2022 at 03:30:32PM +, Kent Watsen wrote:
>
> Here's what is intuitive to me:
>
> - date -MM-DD
> - time hh:mm:ss
>
> Effectively your proposal. I question if "date-with-zone" or
> "time-with-zone" are ever needed.Certainly not "date-wit
On Thu, Apr 7, 2022 at 8:31 AM Kent Watsen wrote:
>
> Hi Juergen,
>
> On Apr 7, 2022, at 3:13 AM, Jürgen Schönwälder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> On Wed, Apr 06, 2022 at 05:49:26PM -0700, IETF Secretariat wrote:
>
>
> The IETF WG state of draft-ietf-netmod-rfc6991-bis has
From: netmod on behalf of Kent Watsen
Sent: 07 April 2022 16:30
Hi Juergen,
On Apr 7, 2022, at 3:13 AM, Jürgen Schönwälder
mailto:j.schoenwael...@jacobs-university.de>>
wrote:
On Wed, Apr 06, 2022 at 05:49:26PM -0700, IETF Secretariat wrote:
The IETF WG state of draft-ietf-netmod-rfc6991-b
Hi Juergen,
> On Apr 7, 2022, at 3:13 AM, Jürgen Schönwälder
> wrote:
>
> On Wed, Apr 06, 2022 at 05:49:26PM -0700, IETF Secretariat wrote:
>>
>> The IETF WG state of draft-ietf-netmod-rfc6991-bis has been changed to "WG
>> Consensus: Waiting for Write-Up" from "Waiting for WG Chair Go-Ahead"
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.
On Thu, Apr 07, 2022 at 08:39:01AM +, 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.
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 appreciate that this is an NBC change, but I believe that this is the most
intuitive definition and is the
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 t
Some of both, apparently ;)
That thread didn’t popup having a different Subject.
Carry on. I can revert the Datatracker state if needed.
K.
> Hey Kent,
>
> Are you behind on your Emails or choosing to ignore the ongoing discussion of
> the ip-address, ipv4-address, and ipv6-address
Here is roughly what happened:
- RFC 6020 (published ~12 years ago) introduced the ip-address
type. It included an optional zone index part since zone indexes
are necessary in certain situations (e.g., configuring services
listening on link-local addresses or clients connecting to services
On Wed, Apr 06, 2022 at 05:49:26PM -0700, IETF Secretariat wrote:
>
> The IETF WG state of draft-ietf-netmod-rfc6991-bis has been changed to "WG
> Consensus: Waiting for Write-Up" from "Waiting for WG Chair Go-Ahead" by Kent
> Watsen:
>
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991
26 matches
Mail list logo
