Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Mar 2020 16:37:10 -0500

Neil (and the working group), I need a response to this, so I can get
back to Michelle.  Is this acceptable to you?

Barry

On Tue, Feb 25, 2020 at 9:04 PM Barry Leiba <[email-masked]> wrote:
>
> I chatted with Michelle Cotton (IANA), and she suggested that it would work better for them if we called the policy Expert Review instead of Specification Required, but still said that we expect a document, etc, as we now say, and the Expert will judge the suitability of that.
>
> No need to make any change now, but please queue it up for when you next make a change.  It’s just a minimal thing at this point.
>
> Barry
>
> On Sun, Feb 23, 2020 at 9:29 PM Barry Leiba <[email-masked]> wrote:
>>
>> All good... onward and forward.
>>
>> b
>>
>> On Sun, Feb 23, 2020 at 6:46 PM Neil Jenkins <[email-masked]> wrote:
>>>
>>> Hi Barry,
>>>
>>> OK, that makes sense.  Maybe it's worth a minor wording change.  Does
>>> something like this work for you
>>>
>>> NEW
>>> A value of 0 specifies an undefined priority, for which the treatment
>>> will vary by situation.
>>> END
>>>
>>>
>>> Yes, I'm happy with that; I've added it in.
>>>
>>> Do you really anticipate extensions that are sufficiently simple, of that sort of nature, that a one-sentence explanation could be sufficient for interoperable implementations?
>>>
>>>
>>> I do, yes. Many properties are that simple.
>>>
>>> Maybe this will work?:
>>>
>>> NEW
>>>    That documentation will usually be in an RFC, but simple
>>>    definitions are likely to use a web/wiki page, and if a sentence
>>>    or two is deemed sufficient it could be described in the registry
>>>    itself.
>>> END
>>>
>>>
>>> That looks good to me, I've adopted that too.
>>>
>>> > — Section 8.4.1 —
>>> >
>>> >    o  Experts: The initial list of experts for Expert Review of updates
>>> >       to the subregistry.
>>> >
>>> > Hm, are you actually proposing that registrations provide their own
>>> > lists of experts, rather than having them appointed by the IESG?  I
>>> > don’t think that’s going to work.  We probably need to have a
>>> > discussion about the intent here, so please initiate that by
>>> > explaining to me what you’re looking for.
>>> >
>>> >
>>> > Suppose a new enum-type property is registered that is not IETF controlled,
>>> > then a new enum subregistry will be created and the designated experts need
>>> > to be given for that subregistry, hence its inclusion in the template. Does that
>>> > make sense?
>>>
>>> Well, Expert Review (or Specification Required) uses experts
>>> designated by (appointed by) the IESG.  Here, it sounds like you're
>>> talking about creating registries that use some other sort of peer
>>> review, using experts not appointed by the IESG -- appointed by, it
>>> seems, whoever creates the registry.  I'm quite sure that IANA will be
>>> unhappy with that, as they aren't set up to consult arbitrary experts
>>> and to track their responses, without having the IESG to act as
>>> managers and do problem resolution.  What happens when the specified
>>> experts disappear -- their email addresses no longer work, or the
>>> experts are unresponsive?  Who deals with that?  We have a whole
>>> process for how expert review works within the IETF, but we don't have
>>> any process for dealing with outside experts.
>>>
>>> So, the *concept* makes sense, but, as the saying goes, the devil is
>>> in the details.
>>>
>>>
>>> OK, understood. I've now made it so the registry is just IETF designated experts (like the others); see the diff in v25. I hope this resolves the issue.
>>>
>>> Cheers,
>>> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 05 Mar 2020 11:29:37 +1100

> back to Michelle. Is this acceptable to you?

Yes, this is fine. I have updated the source; it will be in the next published revision. Apologies for the late reply.

Cheers,
Neil.