Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-ippm-initial-registry-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joel, thanks for your review. Al, thanks for your response. I entered a No Objection ballot.

Alissa


> On Nov 3, 2019, at 4:00 PM, Joel Halpern Direct <jmh.direct@xxxxxxxxxxxxxxx> wrote:
> 
> Thanks Al.  I presumed all the ducks were in a row, but thought I should ask to be certain.
> 
> Yours,
> Joel
> 
> On 11/3/2019 3:14 PM, MORTON, ALFRED C (AL) wrote:
>> 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.
>>> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux