Re: [ippm] AD review of draft-ietf-ippm-metric-registry-19

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Mirja,
Catching-up with your comments on the registry draft.
Please see replies below, and thanks again for your review.
Al

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[e-mail]]
> Sent: Tuesday, August 27, 2019 9:44 AM
> To: [e-mail]
> Cc: IETF IPPM WG <[e-mail]>; Michelle Cotton
> <[e-mail]>
> Subject: AD review of draft-ietf-ippm-metric-registry-19
> 
> Hi all,
> 
> I just reviewed draft-ietf-ippm-metric-registry-19. Thanks for the well-
> written document! I have one process question on the following part before
> we can move ahead:
> 
> Sec 8.1:
>   "Submission to IANA MAY be the result of IETF Standards Action, where
>    an approved Internet Draft proposes one or more Registered
>    Performance Metrics to be added to the Performance Metrics Registry,
>    including the text of the proposed Registered Performance Metric(s).”
> 
> Maybe I’m confused but I would think that as soon as a document is
> approved by the IESG, it’s too late for an Expert review because an
> approved RFC that contains instruction for IANA will usually be
> implemented by IANA as approved. I believe what we usually do is to
> request the new entry before IESG evaluation and simply document in the
> RFC that an registration was performed, or in case of e.g. the port
> registry (where however the policy is IETF Review for system ports) we ask
> the experts for review during the IESG evaluation process and take this as
> input for the IESG to make a decision on approval (rather than as input
> for IANA). I’m cc’ing Michelle, as I understood that she was already
> involved in reviewing this document, and she might have further
> insights/considerations.
[acm] 
I agree, here's what I changed the working text to read:

Submission to IANA MAY be during IESG review (leading to IETF 
Standards Action), where an Internet Draft proposes one or ...

> 
> Also on experts: Did the group/chairs/authors already consider possible
> candidates? If not, is anybody of the author team willing to serve? I
> assume having 2 experts should be sufficient, right?
[acm] 
Yes, I assume I'll act as one of the experts, and we'll need a few more 
who can share the load, especially if a quick response is required.

> 
> Thanks!
> Mirja
> 
> P.S.: Two nits:
> - sec 7.3.2: "The packet generation stream may require parameters such as
> the the average packet rate …” -> two “the”
> - sec 8.2: "why the existing entry shuold be revised” -> s/shuold/should/
[acm] 
thanks, fixed.

Other Questions arose:

Sorry one more thing on references: There are two normative reference to obsoleted RFC (RFC2141 and RFC4148). I think it would be more appropriate to make these references informational instead. Also there is a new Downref to RFC6248, however, I think that could also be an informational reference instead.

[acm]
I agree, I moved 4148 and 6248 to Info, can't find 2141 in the working text, 
assume I deleted it with unused references. 

@Bill: as the document shepherd it would be could to point out these things in the shepherd write-up. If the authors/group decides to move these references to informational, there is no additional action require from you. However, if not, the write-up should be updated accordingly.

Thanks!
Mirja


Here are your questions for the registry
that came-up during review of initial contents draft:

> 
> And finally one/two/three more general question(s) at the end, that I
> probably should also have asked already on my review for draft-ietf-ippm-
> metric-registry:
> 
> Is it actually intended that basically all the text in this RFC gets
> copied into the registry? 
[acm]
Sort of. All the text for each metric (section) is a file that the registry
entry points to. Registry draft section 10.3 says:

The "URIs" column will have a URL to the full template of each registry entry. The Registry Entry text SHALL be HTML-ized to aid the reader, with links to reference RFCs (similar to the way that Internet Drafts are HTML-ized, the same tool can perform the function).

> And what is expected to be on the URL page then?
[acm]
The URL points to a page = one section of the -ippm-initial-registry draft.
Future URLs might point to text from a section of an RFC for a new metric.

> Wouldn’t it be necessary to also define a format for that page in order to
> be of any use?
[acm]
It's the "full template", filled-out for each registered metric.

It really helps to have the mock-up we worked-out with IANA
available to see the "running code". I'll send you the mock-up
in separate mail. We looked at this in several IPPM sessions 
over the years, and on this one the header is fairly up to date,
but the URLs point to "old" sections of the initial contents draft.
Also, the column widths are not ideal in the mock-up.

It might help to have a live URL to the mocked-up registry
that we can share with others (when this question comes up again,
and it will during IESG review, I assure you!).

Al