Re: [mpls] Erik Kline's No Objection on draft-ietf-mpls-lsp-ping-registries-update-08: (with COMMENT)

[Erik Kline <[e-mail]>]

On Mon, Feb 15, 2021 at 3:24 AM Adrian Farrel <[e-mail]> wrote:
>
> Hi,
>
> Last time I checked in with IANA about this (IANA and I were talking past each other about "registries", "top-level registries", "registry pages", and "sub-registries") I think it was on IANA's list of things to do to make a clear terminology for everyone to use.
>
> Obviously, we can't hold up the production of IETF work waiting for that, so the attempt is to write something that is understood by the readers and the primary consumers (including IANA). Consistency with other work may be hard because the use of terms has historically been a bit varied.
>
> I'm sure that direct editorial suggestions would be welcomed by the authors.

I briefly attempted to craft some concrete text before sending the
much shorter observation/comment.

Everything I could think to write seemed like it should have already
been written in some canonical document somewhere.  RFC 8126 has text
to offer, obviously, but may also not be addressing some terminology
need (hence this section in the document).

I mostly wanted to check that I wasn't alone in thinking that perhaps
there might be a larger issue here (that might or might not need to
get addressed separately at a later time).

> -----Original Message-----
> From: Loa Andersson <[e-mail]>
> Sent: 15 February 2021 10:38
> To: Erik Kline <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Adrian Farrel <[e-mail]>
> Subject: Re: Erik Kline's No Objection on draft-ietf-mpls-lsp-ping-registries-update-08: (with COMMENT)
>
> Erik,
>
> inline please.
>
> On 15/02/2021 15:00, Erik Kline via Datatracker wrote:
> > Erik Kline has entered the following ballot position for
> > draft-ietf-mpls-lsp-ping-registries-update-08: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > [[ comments ]]
> >
> > [ section 1.2.1 ]
> >
> > * I find it slightly odd that this section even exists.
> >
> >    RFC 8126 section 1 seems to provide a definition for "namespace" and
> >    for "assignment"/"registration".  My reading of 8126s1's definition
> >    of namespace doesn't seem to quite match this document's use of namespace
> >    (seems more like the definition of registry without the existence of
> >    a definition for "sub-registry"), but maybe I haven't spent enough time
> >    thinking about it.
>
> I kind of agree that it is kind of odd - one would think that something
> as important as the nomenclature around IANA restrings would be set in
> stone. When we started to write this document we found that we were
> talking past each other when talking about different "levels" of IANA
> registries. So we wrote something that could work for THIS dcument,
> without being a suggestion for an IANA registries nomenclature.
>
> I would certainly be willing to work on such a nomenclature, and I find
> it encouraging that IANA have started to talk about the hightest level
> of registries listed on https://www.iana.org/protocols as categories and
> seem to be willing to introduce  sub-categories.
>
> /Loa
> >
> >    If IANA review is fine with this text here, I've no objection.
> >
> >
> > [[ nits ]]
> >
> > [ section 1 ]
> >
> > * "there hav been" -> "there have been"
> >
> >
> >
>
> --
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]
>