Subject: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-2330-ipv6-05: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Jun 2018 19:24:10 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ippm-2330-ipv6-05: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/

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

I'm glad to see that the "class C" potential confusion is already being
addressed.  Even having seen that previous discussion, I was still struck by
how my mind jumped to "address class" when reading it.

The Abstract claims that this document " deprecates the definition of minimum
standard-formed packet", but the body text refers only to a "minimal IP packet".

A couple of nits:

Section 4

   Two mechanisms require some discussion in the context of standard-
   formed packets, namely IPv6 over Low-Power Wireless Area Networks
   (6LowPAN, [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]).
   IPv6 over Low-Power Wireless Area Networks (6LowPAN), as defined in
   [RFC4494] and updated by [RFC6282] with header compression and
   [RFC6775] with neighbor discovery optimizations proposes solutions
   for using IPv6 in resource-constrained environments.

Please put a comma before "proposes"

Maybe I should leave this one for the RFC Editor, but this document uses
"exemplary" twice when I think "example" is more appropriate -- to me,
"exemplary" means something like "best in class" and specifically has a
positive connotation, whereas these usages are for things that have ambivalent
or negative connotations.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 21 Jun 2018 18:39:44 +0000

Hi Benjamin,
Thanks for your review, please see replies below.

> -----Original Message-----
> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2018 10:24 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Brian Trammell <[email-masked]>;
> Nevil Brownlee <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-ippm-2330-ipv6-05:
> (with COMMENT)
> 
...
[acm] 
Sure. 
It's equally striking to me that this terminology overload 
wasn't flagged in the original development of RFC 2330 (where the
notion of a class C of packets was first introduced, 20 years ago)
https://tools.ietf.org/html/rfc2330#page-19
or when we developed the definition further in RFC 7799, end of section 3.8
https://tools.ietf.org/html/rfc7799#page-8
(much more recently). 
And again on the topic of route metrics in
https://tools.ietf.org/html/draft-ietf-ippm-route-01#section-3.5
last paragraph.  I'll add the clarifying phrases before this memo
reaches IESG.

> standard-formed packet", but the body text refers only to a "minimal IP
[acm] 
Thanks for catching that. "minimal IP packet" is the correct term from
RFC2330, and we'll update the abstract.

> Please put a comma before "proposes"
[acm] OK  ,proposes
;-)

> or negative connotations.
[acm] easy to fix now since we're pushing changes,
and reduce the Q/A with RFC Editors.

thanks again,
Al