Samier's response is needed to initiate the adoption call.
Kent // co-chair
> On Dec 6, 2022, at 1:15 PM, Oscar González de Dios
> wrote:
>
> Dear NETMOD WG chairs, all,
>
>No, I'm not aware of any IPR that applies to this draft.
>
>Our co-author Samier has changed
> Nobody has asked for a 'name' version yet. I just wanted to use this
> example that demonstrate that it is hard to future proof name
> choices.
Fine. The intended pattern wasn't clear. Knowing that there is a pattern,
it's fine to not have a "name" version. Should the draft capture the
> On Dec 9, 2022, at 11:27 AM, Jürgen Schönwälder
> wrote:
>
> On Fri, Dec 09, 2022 at 03:41:05PM +, Kent Watsen wrote:
>>
>> 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
On Fri, Dec 9, 2022 at 8:29 AM Acee Lindem (acee) wrote:
> 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
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
On Fri, Dec 09, 2022 at 03:41:05PM +, Kent Watsen wrote:
>
> 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
On Fri, Dec 09, 2022 at 04:00:08PM +, Kent Watsen wrote:
>
> Hi Juergen,
>
>
> >> I may've been thrown off by the following "no-zone" types...should they be
> >> named consistently?
> >>
> >> - date-no-zone --> date-no-zone-offset or date-without-zone-offset
> >> - time-no-zone
Hi Juergen,
>> I may've been thrown off by the following "no-zone" types...should they be
>> named consistently?
>>
>> - date-no-zone --> date-no-zone-offset or date-without-zone-offset
>> - time-no-zone --> time-no-zone-offset or time-without-zone-offset
>
> The 'no-zone'
> 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
