Hi,
Christian Hopps wrote:
>
> Martin Bjorklund writes:
>
> > Hi,
> >
> > I think one concern with "rfc8199-xxx" is that if this RFC gets reved,
> > the name will be misleading. I also agree that "element" is too
> > vague.
>
> Isn't this why we have "Updates" and "Obsoletes" for? If this al
Martin Bjorklund writes:
Hi,
I think one concern with "rfc8199-xxx" is that if this RFC gets reved,
the name will be misleading. I also agree that "element" is too
vague.
Isn't this why we have "Updates" and "Obsoletes" for? If this all didn't work we could never refer to our
standards by
Hi,
I think one concern with "rfc8199-xxx" is that if this RFC gets reved,
the name will be misleading. I also agree that "element" is too
vague.
Since 8199 doesn't use the terms "element" and "service", but "network
element" and "network service", how about these changes:
ietf:rfc8199-elemen
On Wed, Feb 13, 2019 at 09:40:52AM -0500, Christian Hopps wrote:
>
> But, "ietf:protocol" is in fact intended and defined to be generic,
> "ietf:rfc8199-element" is not defined as generic at all. It's defined very
> clearly in RFC8199. Using a broad tag "ietf:element" for such a narrow
> defini
Juergen Schoenwaelder writes:
On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote:
Juergen Schoenwaelder writes:
But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is
what "rfc8199-element" is supposed to be. It'll need to b
My opinion is that we should just push the doc as it stands now.
I don't know whether we have the perfect set of base tags defined in
section 8.2, but I don't think that this really matters. One of the
things that I prefer about tags, compared to the alternative approach of
having a rigid str
On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote:
>
> Juergen Schoenwaelder writes:
>
> > > > The 'rfc8199-' part in some of the tags does look to me like an
> > > > attempt to scope 'service', 'element' etc. If this is being used, you
> > > > will see that labels will use ad-hoc
Juergen Schoenwaelder writes:
> The 'rfc8199-' part in some of the tags does look to me like an
> attempt to scope 'service', 'element' etc. If this is being used, you
> will see that labels will use ad-hoc forms of scoping. The networking
> vocabulary is small and reuse of terms with differen
First of all, let me clarify that I submitted comments, I did not
raise objections. There is a difference I think.
On Wed, Feb 13, 2019 at 05:19:17AM -0500, Christian Hopps wrote:
>
> Juergen Schoenwaelder writes:
>
> > On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote:
> > >
> >
Juergen Schoenwaelder writes:
On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote:
In any case this is general purpose meta-data after all, while some data may be
immediately recognizable (e.g., ietf:routing) other data may require looking at
a specification to determine it's m
On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote:
>
> In any case this is general purpose meta-data after all, while some data may
> be immediately recognizable (e.g., ietf:routing) other data may require
> looking at a specification to determine it's meaning.
>
Frankly, I can't
Juergen Schoenwaelder writes:
On Tue, Feb 12, 2019 at 03:50:08PM -0800, Joel Jaeggli wrote:
Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as
Proposed Standard on behalf of the NETMOD working group.
Please verify the document's state at
https://datatracker.ietf.
On Tue, Feb 12, 2019 at 03:50:08PM -0800, Joel Jaeggli wrote:
> Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as
> Proposed Standard on behalf of the NETMOD working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-netmod-
Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as
Proposed Standard on behalf of the NETMOD working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
___
netmod mai
14 matches
Mail list logo
