On Tue, 2019-07-23 at 00:07 +0200, Juergen Schoenwaelder wrote:
> On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder writes:
> >
> > > Lada,
> > >
> > > I do not think we can simply enlarge the value set of inet:domain-name,
> > > existing implementations
Hi, all:
Thanks Benoit to remind the YANG side meeting at the end of netmod session.
For folks who might be interested in to talk about the gap between IETF YANG
and industry needs, please join the following side meeting scheduled on Tuesday
morning.
Side meeting: Next Step of IETF YANG; The goal
On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> Juergen Schoenwaelder writes:
>
> > Lada,
> >
> > I do not think we can simply enlarge the value set of inet:domain-name,
> > existing implementations using inet:domain-name may (rightfully) not
> > expect wildcards.
>
> On the
Juergen Schoenwaelder
writes:
Lada,
the definition of inet:domain-name already has text that
Internet host names have a stricter syntax. Perhaps we should
simply state explicitely in the definition of host that the
stricter rules apply?
I understand that you want to capture more in the d
Juergen Schoenwaelder
writes:
Lada,
I do not think we can simply enlarge the value set of
inet:domain-name, existing implementations using
inet:domain-name may (rightfully) not expect wildcards.
On the other hand, the description says:
It is designed to hold various types of domain na
On Mon, Jul 22, 2019 at 07:23:59PM +, Balázs Lengyel wrote:
> Hello,
>
> Restconf (rfc8040) defined to useful bits of metadata about a YANG defined
> datastore: entity-tag and the last-modified timestamp.
>
> These can be very useful in instance data sets, however Restconf defines an
> encodi
Hello,
At the IETF 105 Netmod meeting it was stated that the flexible solution to
define the context schema inline (requested earlier on the mailing list) is
quite complex, so a fourth simpler method to define content schema inline is
needed.
The fourth method would add one more choice to choice
On Mon, 2019-07-22 at 21:08 +0200, Juergen Schoenwaelder wrote:
> Lada,
>
> it seems the IANA 'deprecated' and 'obsolete' as defined in RFC 8126
> section 9.6 both map to YANG's 'obsolete'.
Yes, a short-term fix (e.g. for iana-dns-class-rr-type that is now in DNSOP WG)
could indeed be to map IANA
Hello,
Restconf (rfc8040) defined to useful bits of metadata about a YANG defined
datastore: entity-tag and the last-modified timestamp.
These can be very useful in instance data sets, however Restconf defines an
encoding for these (as part of the http headers) that can not be used in
instance-da
On Mon, 2019-07-22 at 18:46 +, Joe Clarke (jclarke) wrote:
> I’ve had a chance to digest the question asked in the meeting about should the
> last-modified and entity-tag should be defined in the instance data draft.
>
> I feel they should be removed and moved to a separate draft. First, the
Lada,
it seems the IANA 'deprecated' and 'obsolete' as defined in RFC 8126
section 9.6 both map to YANG's 'obsolete'.
/js
On Mon, Jul 22, 2019 at 02:49:18PM -0400, Ladislav Lhotka wrote:
> Hi,
>
> I haven't received any responses to my message below but, given the recent
> discussion in DNSOP a
Hi,
I haven't received any responses to my message below but, given
the recent discussion in DNSOP and IETF mailing list, I believe it
is important to address this discrepancy in order not to give
ammunition to those who oppose mirroring IANA registries in YANG
modules.
Lada
Ladislav Lhotk
I’ve had a chance to digest the question asked in the meeting about should the
last-modified and entity-tag should be defined in the instance data draft.
I feel they should be removed and moved to a separate draft. First, the draft
doesn’t present a use case for these. There is already an over
13 matches
Mail list logo
