[alto] Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

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

Murray Kucherawy has entered the following ballot position for
draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-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-alto-unified-props-new/



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

I support Francesca's DISCUSS.

The shepherd writeup says:

  The chair has received IPR declarations from Richard Yang, Sabine Randriamasy,
  Jensen Zhang, Wendy Roome, and Kai Gao.  During the discussion of this I-D
  in the working group, no IPR issues has been raised to the best of my
  knowledge.

Just to be clear, I presume what the chair actually received was affirmations
of compliance with BCP 78 and 79 from those people, and not declarations of the
existence of IPR.

The "Interoperability considerations" part of Section 12.1 doesn't seem to be a
complete answer to the corresponding guidance in Section 6.2 of RFC 6838.

I'm bothered by the dangling SHOULD in Section 12.2.2.  If you're going to
include that, I suggest including some guidance about when it would be
legitimate to omit that information from a registration and still expect it to
go through.

The second-last paragraph in Section 12.3 appears to be broken.

For Sections 12.2 and 12.3, I suggest not including a registry entry for
"priv:" because that's not an identifier, but everything else is.  It's fine to
leave in prose saying nothing can be registered using "priv:" as a prefix, as
those are meant to indicate private use.

[I-D.gao-alto-fcs] has expired.  What's the plan here?  It's an informative
reference.

I had the same thought as Ben did about the use of "GET-mode" and "POST-mode".

It's a pity that the referenced documents didn't use ABNF, because it seems
like Sections 5.1.1 and 5.1.2 would benefit from it.  But ultimately, I agree
with the decision to be consistent.

Also in 5.1.1, it seems strange to issue constraints for how private use entity
domain types are to be specified.  If they're private use, interoperability is
the concern of those participants only.

Sections 6.1.1.1 and 6.1.2.1 (and later, 6.2.1) should include more than a
single word.  I suggest something like:

  The identifier for this Entity Domain Type is "ipv4".

In Section 6.2.3, "is" should be "are".

Do we need Section 7.3?  If we do, please turn it into at least a single
sentence, like:

  A Property Map has no Accept Input parameters.