[Add] Murray Kucherawy's Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS and COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-add-resolver-info-12: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In Section 8.2, we're creating an IANA registry with Specification Required
rules.  You correctly cite Section 4.6 of BCP 26, but that section also says:

   As with Expert Review (Section 4.5), clear guidance to the designated
   expert should be provided when defining the registry, and thorough
   understanding of Section 5 is important.

Such guidance appears to be absent here.  What do you have in mind?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Section 5:

  "Note that, as per the rules for the keys defined in Section 6.4 of
  [RFC6763], if there is no '=' in a key, then it is a boolean attribute,
  simply identified as being present, with no value."

I don't know what it means for a Boolean value to be "present".  Do you mean
that its presence in the record indicates the value is "true"?

The last few sentences of the description of "infourl" seem awfully hand-wavy. 
You might want to simplify this by saying it's a URI referring to content that
may be useful for debugging, and just leave it at that.  And I don't understand
the SHOULD here; what's the alternative you're trying to discourage?

Once the list of registered RESINFO keywords is big enough, it's possible to
pack enough of them into one of these records to cause truncation and a switch
to TCP.  Should we be encouraging registration of shorter names wherever
possible to forestall this?