[pim] John Scudder's No Objection on draft-ietf-pim-igmp-mld-extension-06: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-pim-igmp-mld-extension-06: 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-pim-igmp-mld-extension/



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

Thanks for this document. It’s clear and useful. I have a few comments I hope
may be helpful.

1. I’d like to echo Rob Wilton’s first comment, about how the use of the term
“extension” to mean slightly different things at different points is not
helpful to readability. Concretely:

- Maybe the title could be something like “… Message Extensibility Mechanism”
instead of “… Message Extension”?

- As Rob points out the use of “extension” is particularly vexatious in §5. I
like his suggestion of using “extension TLVs” although there are many other
options, for example you could say “… new extension types”.

2. In Section 1 you say “Additional Data is defined for…” and then go on. On
first glance, I thought maybe you meant that there was existing use of the
Additional Data field in the cited documents (which would have necessitated
some further discussion, perhaps). This minor confusion would be easily
prevented by changing to say “The Additional Data field is defined…”

3. Apropos the above, I suppose I don’t need to worry about whether there is
legacy use of the Additional Data field, because your introduction of the E-bit
takes care of that concern?

4. I was surprised you don’t reserve anything at all out of your 2^16 code
point space for experimental use or development. Given that you’ve specified a
relatively restrictive allocation policy (IETF Review), what’s your expectation
for how people will work on under-development extensions? Are they expected to
just squat on code points? It seems like a case of training people to behave
badly by not giving them any options for behaving well. :-(

5. Speaking of code points, I like the suggestion mentioned in Ben’s review,
that it might be a good idea to define a noop TLV in this document.