Hi Joel, Thanks for your review, please see replies below. Al > -----Original Message----- > From: Joel Halpern via Datatracker [mailto:noreply@xxxxxxxx] > Sent: Friday, November 1, 2019 12:55 PM > To: gen-art@xxxxxxxx > Cc: last-call@xxxxxxxx; draft-ietf-ippm-initial-registry.all@xxxxxxxx; > ippm@xxxxxxxx > Subject: Genart last call review of draft-ietf-ippm-initial-registry-12 > > Reviewer: Joel Halpern > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwICaQ&c=LFYZ- > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=GTgiUHp01_savOvQS49iOt8XRHfRw > hPgZj-TNotgKGk&s=M0ib3zYg2qffmRujLJv2h_WHQ16W9fOYat9hNtBqcFk&e=>. > > Document: draft-ietf-ippm-initial-registry-12 > Reviewer: Joel Halpern > Review Date: 2019-11-01 > IETF LC End Date: 2019-11-06 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as a Proposed Standard > > Side note: I presume that as part of the process for > draft-ietf-ippm-metric-registry (the normative reference the defines the > structure used in this document) there has been discussion with IANA explicitly > about the fact that this registry has an extremely large number of > columns, some with extremely verbose content, and it will likely take some work for > IANA to determine how to present this in a human-readable fashion? And the > lesser point that is probably covered by existing procedures, but I wanted to > check, that IANA is prepared to fill in the URLs scattered throughout the > document? [acm] Yes and Yes. We prepared a mock-up of the new Registry at various stages of development. Humbly, it was my idea to make the registry entries both readable and useful. The IANA reps suggested the mock-up early-on, and we have shared the different versions with the IPPM WG. We/IANA plan to make the mock-up more widely available (but we failed to do that in time for Last Call). > > Second note: I did not review the accuracy of the descriptions of the metrics, > but only looked for clarity. This is material well known to the WG, and mostly > derived from other documents this or closely related working groups have > produced. > > Major issues: N/A > > Minor issues: > For those entries that are defining two (or more) closely related metrics, > should the document actually have two (or more) lines for URL, since the > text says that IANA is to assign two URLs. (And the list of differing > fields should presumably include URL?) [acm] There are sections of the document that define more than one registry entry, so yes, there will be >1 URLs, etc. in the corresponding rows. > > In the first part of section 5, there is a note about potentially splitting > the registry entry into two registry entries. I can not understand the > note. The registry is either defined with one entry or defined with two > entries. Is this still an open item? (If so, my "ready" above clearly > should be "Ready with issues.") I think it is just an erroneous retention > of text from earlier? [acm] Exactly, it is a note left-stranded by editing later in the section, thanks for catching it - deleted in the working version. > > Nits/editorial comments: > If there are no roles to define in 5.3.6, shouldn't it say "N/A" [acm] Actually, it should define the Roles (Src and Dst) as with other Metrics. Something went wrong with formatting here - the text below the section header disappeared... thanks for catching that! > Some comments and remarks say "None" which makes sense. Some say > "Additional (Informational) details for this entry" which seems to be > text left over from the template that should say "None"? [acm] Right, found and replaced in working copy. > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
