Re: [core] Murray Kucherawy's Discuss on draft-ietf-core-problem-details-05: (with DISCUSS and COMMENT)

[Francesca Palombini <[e-mail]>]

Hi Murray,

The new version the authors posted should address your DISCUSS (https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/ballot/ ), could you take a look and see? Diff here: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-problem-details-06.txt


Thanks,
Francesca

From: core <[e-mail]> on behalf of Carsten Bormann <[e-mail]>
Date: Thursday, 16 June 2022 at 12:39
To: Murray Kucherawy <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, The IESG <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [core] Murray Kucherawy's Discuss on draft-ietf-core-problem-details-05: (with DISCUSS and COMMENT)
Hi Murray,

thank you for examining the IANA considerations of this document closely.
We already have reacted to the comment from IANA that pointed out they cannot perform the checks they would need to do with the “first-come first-serve” policy for 5.2.  So we had been making a few changes to the IANA considerations section, which we continue with this response.

Detailed responses (and further changes) below.
The most recent changes based on your feedback are collected in:

https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2856dc9115511197&q=1&e=164273fd-2220-449f-8b83-61d5d6a0dee6&u=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fcore-problem-details%2Fpull%2F39

Probably the whole thing is easier to read in the consolidated editor’s copy at

https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-cdd36cb5d1724fc1&q=1&e=164273fd-2220-449f-8b83-61d5d6a0dee6&u=https%3A%2F%2Fcore-wg.github.io%2Fcore-problem-details%2Fdraft-ietf-core-problem-details.html%23name-iana-considerations

> On 2022-06-16, at 11:02, Murray Kucherawy via Datatracker <[e-mail]> wrote:
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-core-problem-details-05: Discuss
>
> […]
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This should be quick to clear up, but the IANA Considerations section has a few
> issues:
>
> Section 5.1 declares a new registry with a Specification Required policy.  RFC
> 8126 explains what this means in its Section 4.6, and notes that this will
> result in a Designated Expert being appointed, and further stipulates that
> "clear guidance to the designated expert should be provided when defining the
> registry".  However, none is evident here.  Was this an oversight?

We had added some expert review guidance already in the most recent version, prompted by the IANA comments.

We now added some more text in Section 5.1 (now 6.1), which should now be a more complete set of instructions.

> Section 5.2 declares a new registry with a First Come First Served policy.  RFC
> 8126, Section 4.4, covers this, and says in pertinent part, "... in addition to
> the contact person field or reference, the registry should contain a field for
> change controller."  That's absent here, so please add one.

(While this is “expert review” now, the same consideration applies.)

We are just wondering why Section 4.6 of RFC 8126 does not have that requirement.  Anyway, we added Change Controller to both 5.1 (now 6.1) and 5.2 (now 6.2).

> In Section 5.3, the "Required Parameters" and "Optional Parameters" need to be
> "N/A", not "None".  See RFC 6838, Section 5.6.

Fixed.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> With respect to the comment at the end of Section 5.4, is some other document
> altering the names of those registry columns?

I’m afraid not at this time.  https://datatracker.ietf.org/doc/draft-bormann-core-corr-clar/ was meant to collect corrections and clarifications to the base specification, but so far we didn’t see a need to push this through all the way to RFC (we didn’t even do working group adoption yet, and much of the discussion in the issues still needs to be processed).

Maybe it’s time to put some more energy into this draft.
I updated https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a0b8e24a6727161b&q=1&e=164273fd-2220-449f-8b83-61d5d6a0dee6&u=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fcorrclar%2Fissues%2F8 for this issue.

Grüße, Carsten

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core