Subject: Re: [Last-Call] [ippm] Genart last call review of draft-ietf-ippm-metric-registry-20

From: Alissa Cooper <[email-masked]>
Date: Wed, 4 Dec 2019 11:15:29 -0500

Roni, thanks for your review. Al, thanks for your response. I entered a DISCUSS ballot to get the registration policy clarified.

Alissa

> On Nov 1, 2019, at 11:54 AM, Roni Even (A) <[email-masked]> wrote:
> 
> Hi Al,
> I saw that IANA was consulted during the work.
> I was wondering what will be the actual text that will be written in the IANA registry, I expected section 10 to describe it.
> 
> Registration Procedure(s)
> Reference
> Note
> 
> I am not sure yet what is the Registration Procedure and what will be written in the Note
> 
> Thanks
> Roni
> 
> -----Original Message-----
> From: Gen-art [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
> Sent: Thursday, October 31, 2019 11:52 PM
> To: Roni Even; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Genart last call review of draft-ietf-ippm-metric-registry-20
> 
> Hi Roni,
> thanks for your comments, please see replies below.
> Al
> 
>> -----Original Message-----
>> From: Roni Even via Datatracker [mailto:[email-masked]]
>> Sent: Tuesday, October 29, 2019 4:25 AM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; draft-ietf-ippm-metric- 
>> [email-masked]
>> Subject: Genart last call review of draft-ietf-ippm-metric-registry-20
>> 
>> Reviewer: Roni Even
>> Review result: Almost 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=mLefZkw5Y_ld2AFv2msgpzOV5
>> Z7lZ JkKTdUQf48X15g&s=uUg9ktSDILsslqK-rG4YIc3gMW0n6oCa-7Dk0xtFZRo&e=>.
>> 
>> Document: draft-ietf-ippm-metric-registry-??
>> Reviewer: Roni Even
>> Review Date: 2019-10-29
>> IETF LC End Date: 2019-11-06
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary:
>> The document is almost ready for publication as a BCP document
>> 
>> Major issues:
>> 
>> Minor issues:
>> 1. From reading the document it looks to me that the registration 
>> policy should be specification required which also requires expert review.
> [acm]
> I understand that perspective. In early review with IANA we decided on Expert Review partly because two elements of registry entries require references to immutable documents, such as standards specifications.
> So the requirement for specifications could be seen as built-in.
> But we may change to Specification Required now, the last IANA review is in-progress. 
> 
>> 2. My understanding is that for registration a document is required , 
>> not necessarily and RFC, but in multiple places in the document ( 7.3, 
>> 7.3.1, 8.2 ,...) the text talks about RFC and not document.
> [acm]
> Yes, a few of those slipped through, thanks.
> 
>> 3. I am not sure if section 6 is needed in the published document based on its content. 
> [acm]
> it's fairly easy for new implementers to pick-up an IPPM RFC (even a STD) and choose parameters that meet their needs. But for the additional advantage of measurement comparisons, more context is needed. Some may even ask why this registry requires the many details. Answer: See section 6.
> A little history is good. Very few have been joining IPPM sessions long enough to know this history.
> 
>> If it will remain then in 6.1
>> first paragraph the reference should be to section 5 and not to section 6.
> [acm] ok
> 
>> 4.
>> In sections 10.2 and 10.3 there are guidance taken from this document. 
>> I think that the for IANA it should say in the registry note that the 
>> registration must comply with RFCXXX (this document), I assume that 
>> there is no need to repeat all this text in these sections in the registry note.
> [acm]
> I have said on a few occasions that almost the entire memo contains IANA Considerations. Nevertheless, we wrote and reviewed the memo and (then wrote) the separate IANA section with IANA's help.
> 
> I have implemented the agreed changes above in the working version.
> Thanks again!
> 
>> 
>> Nits/editorial comments:
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 4 Dec 2019 17:35:00 +0100

Hi Alissa,

Section 10.1 say:

Registration Procedure: Specification Required

What else do you think is needed?

Mirja

> On 4. Dec 2019, at 17:15, Alissa Cooper <[email-masked]> wrote:
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 4 Dec 2019 17:49:32 +0000

Hi Alyssa,

Although we originally chose Expert Review (at IANA's request),
it seems the best policy choice is Specification Required
(which includes Expert Review), and IANA agreed at IETF-106.
  
We are in the process of finding and updating any stray instances 
of the old policy left behind...

Al

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Wednesday, December 4, 2019 11:15 AM
> To: Roni Even (A) <[email-masked]>
> Cc: MORTON, ALFRED C (AL) <[email-masked]>; Roni Even
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-metric-
> registry-20
> 
> Roni, thanks for your review. Al, thanks for your response. I entered a
> DISCUSS ballot to get the registration policy clarified.
> 
> Alissa
> 
> 
> > I was wondering what will be the actual text that will be written in the
> IANA registry, I expected section 10 to describe it.
> >
> > I understand that perspective. In early review with IANA we decided on
> Expert Review partly because two elements of registry entries require
> references to immutable documents, such as standards specifications.
> > it's fairly easy for new implementers to pick-up an IPPM RFC (even a
> STD) and choose parameters that meet their needs. But for the additional
> advantage of measurement comparisons, more context is needed. Some may
> even ask why this registry requires the many details. Answer: See section
> 6.
> > I have said on a few occasions that almost the entire memo contains IANA
> Considerations. Nevertheless, we wrote and reviewed the memo and (then
> wrote) the separate IANA section with IANA's help.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_gen-2Dart&d=DwIFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=2q0aurIg38tkrrArxC6BhJGR8A6r9_B7X9X70h7rmHQ&s=BkWy-
> yUsZUaGgC7d2gETnsQFmV-csAXHbUCx9lPc5RA&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIFAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=2q0aurIg38tkrrArxC6BhJGR8A6r9_B7X9X70h7rmHQ&s=jk9faC1UKfhHsvFGPWHn
> cO7MjzGlPGlIPOewNjeSY6s&e=

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 4 Dec 2019 13:00:23 -0500

Hi Mirja,

> On Dec 4, 2019, at 11:35 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> Section 10.1 say:
> 

What I put in my ballot:

"I'm confused about what the registration policy is for metrics in the new registry. If it is Specification Required, then the places in the document that assume new metrics are defined in an RFC need to be generalized, because Specification Required need not involve any RFC at all.”

Best,
Alissa

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 5 Dec 2019 08:16:25 +0000

Hi,
I think that Al addressed most of them, noted the following are still not clear

Section 3 bullet 1 has RFC
Section 7.1.2  for "spec:" talks about RFC, should be more general say if the specification is RFC then ...
Section 7.1.2 talks only about RFC
Section 7.1.3
Section 7.1.7
Section 7.2 (In 7.2.1 talks about immutable document)
Section 7.3.1 end of the first paragraph
Section 8.1 first paragraph and third paragraph
Section 11.2
Section 11.3
Section 11.5.2  what is the requestor is it a document or person?

New comment:

In section 10.3 can the reference be a contact person since the policy is specification required

Roni Even

> Sent: Wednesday, December 04, 2019 8:00 PM
> To: Mirja Kuehlewind
> Cc: Roni Even (A); MORTON, ALFRED C (AL); Roni Even; [email-masked]; last-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-metric-registry-
> 20
> 
> Hi Mirja,
> 
> "I'm confused about what the registration policy is for metrics in the new
> registry. If it is Specification Required, then the places in the document that
> assume new metrics are defined in an RFC need to be generalized, because
> Specification Required need not involve any RFC at all.”
> 
> Best,
> Alissa
> 
> >
> > Mirja
> >
> >
> >
> >>> From: Gen-art [mailto:[email-masked]] On Behalf Of
> MORTON,
> >>> ALFRED C (AL)
> >>> Cc: [email-masked];
> >>> [email-masked]; [email-masked]
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=mLefZkw5Y_ld2AFv2
> msgpz
> >>>> OV5 Z7lZ
> >>>> JkKTdUQf48X15g&s=uUg9ktSDILsslqK-rG4YIc3gMW0n6oCa-
> 7Dk0xtFZRo&e=>.
> >>>>
> >>>> 2. My understanding is that for registration a document is required
> >>>> , not necessarily and RFC, but in multiple places in the document (
> >>>> 7.3, 7.3.1, 8.2 ,...) the text talks about RFC and not document.
> >>> [acm]
> advantage of measurement comparisons, more context is needed. Some
> may even ask why this registry requires the many details. Answer: See
> section 6.
> >>>> I think that the for IANA it should say in the registry note that
> >>>> the registration must comply with RFCXXX (this document), I assume
> >>>> that there is no need to repeat all this text in these sections in the
> registry note.
> >>> [acm]
> >>> I have said on a few occasions that almost the entire memo contains
> IANA Considerations. Nevertheless, we wrote and reviewed the memo and
> (then wrote) the separate IANA section with IANA's help.
> >>>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 5 Dec 2019 14:04:25 +0000

Hi Roni,

Please keep in mind that this is not a global replacement
for RFC -> Specification.

Some steps in the process apply only to IESG review
with IANA review. Others apply more broadly and we 
only need to change those.

Please help by making your recommendation for 
changes keeping in mind those two categories.

thanks,
Al

> From: Roni Even (A) [mailto:[email-masked]]
> Sent: Thursday, December 5, 2019 3:16 AM
> To: [email-masked]; [email-masked]; MORTON, ALFRED C (AL)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; Mirja
> Kuehlewind <[email-masked]>; Alissa Cooper <[email-masked]>
> Subject: RE: [ippm] Genart last call review of draft-ietf-ippm-metric-
> registry-20
> 
> Hi,
> registry-
> > >>> But we may change to Specification Required now, the last IANA
> review
> > is in-progress.
> > >>>
> > >>>> 3. I am not sure if section 6 is needed in the published document
> based
> > on its content.
> > >>> [acm]
> > >>> A little history is good. Very few have been joining IPPM sessions
> long
> > enough to know this history.
> > >>>
> > >>>> first paragraph the reference should be to section 5 and not to
> section
> > 6.
> > >>> [acm] ok
> > >>>
> > >>>> 4.
> 3A__www.ietf.org_mailman_listinfo_gen-2Dart&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=gzuad-V-
> BNukSa9xX1XrkjMj1QZalBXLPIiwWdbDATE&s=vQLx27IlYqGWfgVPigggpoWFfBJX5TJxz8oU
> Pu2NQp0&e=
> > >>>
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=gzuad-V-
> BNukSa9xX1XrkjMj1QZalBXLPIiwWdbDATE&s=HKT1QAvRtO4211JXIR5edFGw5AS6H94f4tFm
> saAwWRQ&e=
> > >>
> > >>
> > >

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 9 Dec 2019 13:10:06 +0000

Hi Al,

Here are the proposed changes for the -22 version. See if they make sense

Section 3 bullet 1 has RFC change (up to and including the publication of one or more RFCs or  I-Ds describing it) to (up to and including the publication of one or more immutable document such as an RFC)

Section 7.1.2  change “Spec: RFC number and major section number that specifies this” to “Spec: an immutable document, for RFC the RFC number and major section number that specifies this”

Section 7.1.3 change “The URL SHALL reference a target file that is HTML-formated and contains URLs to referenced sections of HTML-ized RFCs” to “The URL SHALL reference a target file that is HTML-formated and contains URLs to referenced sections of HTML-ized reference document” 

Section 7.1.7 change “a new RFC is published that changes the  registry format.”  to “a new document is published that changes the  registry format.” 

Section 7.2 change “This category includes columns to prompt all necessary details related to the metric definition, including the RFC reference and  values of input factors, called fixed parameters, which are left open  in the RFC but have a particular value defined by the performance  metric.” to  “This category includes columns to prompt all necessary details related to the metric definition, including the document reference and  values of input factors, called fixed parameters, which are left open  in the document  but have a particular value defined by the performance  metric.”

Note that In 7.2.1 talks about immutable document

Section 7.3.1 change “for implementations referring to the RFC text.” to “for implementations referring to the immutable document text.”

Section 8.1 first paragraph change “compliance with other applicable Performance Metric-related RFCs,” to “compliance with other applicable Performance Metric-related documents,”

In section 10.3 “The "Reference" column will include an RFC number, an approved specification designator from another standards body, other immutable document, or the contact person.” Remove “or the contact person”

Section 11.2 change “including the RFC reference” to “including the document reference”
 
Section 11.3 change “to relevant sections of  the RFC(s) ” to relevant sections of  the document(s)”

Roni

> From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> Sent: Thursday, December 05, 2019 4:04 PM
> To: Roni Even (A); [email-masked]; [email-masked]
> Kuehlewind; Alissa Cooper
> Subject: RE: [ippm] Genart last call review of draft-ietf-ippm-metric-registry-
> 20
> 
> Hi Roni,
> 
> Please keep in mind that this is not a global replacement for RFC ->
> Specification.
> 
> Some steps in the process apply only to IESG review with IANA review.
> Others apply more broadly and we only need to change those.
> 
> Please help by making your recommendation for changes keeping in mind
> those two categories.
> 
> thanks,
> Al
> 
> > Section 7.2 (In 7.2.1 talks about immutable document) Section 7.3.1
> > end of the first paragraph Section 8.1 first paragraph and third
> > paragraph Section 11.2 Section 11.3 Section 11.5.2  what is the
> > requestor is it a document or person?
> >
> >
> > New comment:
> >
> > > Cc: Roni Even (A); MORTON, ALFRED C (AL); Roni Even;
> > > [email-masked];
> > last-
> > > > On Dec 4, 2019, at 11:35 AM, Mirja Kuehlewind
> > > > <[email-masked]>
> > > wrote:
> > > >
> > > > Hi Alissa,
> > > >
> > > > Section 10.1 say:
> > > >
> > > "I'm confused about what the registration policy is for metrics in
> > > the
> > new
> > > assume new metrics are defined in an RFC need to be generalized,
> > > because Specification Required need not involve any RFC at all.”
> > >
> > > Best,
> > > Alissa
> > >
> > > >
> > > > Mirja
> > > >
> > > >
> > > >
> > > >> Roni, thanks for your review. Al, thanks for your response. I
> > > >> entered
> > a
> > > >>> On Nov 1, 2019, at 11:54 AM, Roni Even (A)
> > > >>> <[email-masked]>
> > > wrote:
> > > >>>
> > > >>> Hi Al,
> > > >>> I was wondering what will be the actual text that will be
> > > >>> written in
> > the
> > > >>>> 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.
> > > >>>>
> > > >>>> 1. From reading the document it looks to me that the
> > > >>>> registration policy should be specification required which also
> > > >>>> requires expert
> > > review.
> > > >>> [acm]
> > > >>> I understand that perspective. In early review with IANA we
> > > >>> decided
> > on
> > > Expert Review partly because two elements of registry entries
> > > require references to immutable documents, such as standards
> specifications.
> > > >>>> 2. My understanding is that for registration a document is
> > > >>>> required , not necessarily and RFC, but in multiple places in
> > > >>>> the document ( 7.3, 7.3.1, 8.2 ,...) the text talks about RFC and not
> document.
> > > >>> [acm]
> > > STD) and choose parameters that meet their needs. But for the
> > > additional advantage of measurement comparisons, more context is
> > > needed. Some may even ask why this registry requires the many
> > > details. Answer: See section 6.
> > > >>>> I think that the for IANA it should say in the registry note
> > > >>>> that the registration must comply with RFCXXX (this document),
> > > >>>> I assume that there is no need to repeat all this text in these
> > > >>>> sections in
> > the
> > > registry note.
> > > >>> [acm]
> > > IANA Considerations. Nevertheless, we wrote and reviewed the memo
> > > and (then wrote) the separate IANA section with IANA's help.
> > > >>>
> 6zYMI&m=gzua
> > d-V-
> BNukSa9xX1XrkjMj1QZalBXLPIiwWdbDATE&s=vQLx27IlYqGWfgVPigggpoWFf
> BJX5TJx
> > z8oU
> > Pu2NQp0&e=
> > > >>>
> 6zYMI&m=gzua
> > d-V-
> BNukSa9xX1XrkjMj1QZalBXLPIiwWdbDATE&s=HKT1QAvRtO4211JXIR5edFGw
> 5AS6H94f
> > 4tFm
> > saAwWRQ&e=
> > > >>
> > > >>
> > > >

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 9 Dec 2019 21:22:53 +0000

Thanks Roni!

I'm glad you took this on, the long sets of comments/DISCUSS
from Benjamin kept me very busy while I was flying 
again - literally all day on Sunday to reach Kona, HI.
You'll see those replies after I sort-out a few more
details today, also Magnus' DISCUSS. It seemed as though
whenever all DISCUSSes on a memo were cleared, someone
pooped in a new DISCUSS to be sure that neither memo was 
Approved, even something trivial. Benjamin entered his DISCUSS
after the telechat!

Have you seen this with other memos?

I'll check and work these-in next,
Al

> Sent: Monday, December 9, 2019 8:10 AM
> To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]; last-
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Section 3 bullet 1 has RFC change (up to and including the publication of
> one or more RFCs or  I-Ds describing it) to (up to and including the
> publication of one or more immutable document such as an RFC)
> 
> Section 7.1.2  change “Spec: RFC number and major section number that
> specifies this” to “Spec: an immutable document, for RFC the RFC number
> and major section number that specifies this”
> 
> 
> Section 7.1.3 change “The URL SHALL reference a target file that is HTML-
> formated and contains URLs to referenced sections of HTML-ized RFCs” to
> “The URL SHALL reference a target file that is HTML-formated and contains
> URLs to referenced sections of HTML-ized reference document”
> 
> Section 7.1.7 change “a new RFC is published that changes the  registry
> format.”  to “a new document is published that changes the  registry
> format.”
> 
> Section 7.2 change “This category includes columns to prompt all necessary
> details related to the metric definition, including the RFC reference and
> values of input factors, called fixed parameters, which are left open  in
> the RFC but have a particular value defined by the performance  metric.”
> to  “This category includes columns to prompt all necessary details
> related to the metric definition, including the document reference and
> values of input factors, called fixed parameters, which are left open  in
> the document  but have a particular value defined by the performance
> metric.”
> 
> Section 7.3.1 change “for implementations referring to the RFC text.” to
> “for implementations referring to the immutable document text.”
> 
> Section 8.1 first paragraph change “compliance with other applicable
> Performance Metric-related RFCs,” to “compliance with other applicable
> Performance Metric-related documents,”
> 
> In section 10.3 “The "Reference" column will include an RFC number, an
> approved specification designator from another standards body, other
> immutable document, or the contact person.” Remove “or the contact person”
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Dec 2019 13:27:49 -0800

> Have you seen this with other memos?

It is quite unusual.
I only did it with the approval of the responsible AD, given that the
documents in question were added to the telechat agenda late, and pushing
the 'defer' button instead would have meant a two-week (or more!) delay.

-Ben

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 9 Dec 2019 21:44:39 +0000

> From: ippm [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
> Sent: Monday, December 9, 2019 4:28 PM
> To: MORTON, ALFRED C (AL) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-ippm-
> [email-masked]
> Subject: Re: [ippm] [Last-Call] Genart last call review of draft-ietf-
> ippm-metric-registry-20
> 
[acm] 
Thanks Ben! Your comments are very detailed - why they took extra
consideration to address, with a little more work to do.

Last week was one of the most stressful of my career, 
with 2 years of design, lab tests and field tests, plus
crazy comment resolution hanging in the balance for Approval
in ITU-T SG12. 

On top of that, trying to meet Mirja's goal of clearing all comments
and DISCUSSes by Wednesday night, so there would be a clean copy
for the telechat - the comments kept coming and we didn't make it.
But a lot of comments and one DISCUSS were cleared.

You'll replies shortly, and we con work-out the last details
as necessary.

Al

> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=kB6TNupdXjwc3qtP2RpoPO2f9DEfd
> GA001X5NKqNh9o&s=hj4tXdvpaN6IEsG_-JiOCTIFlq6FaAGdV-54epvF8JI&e=

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 11 Dec 2019 01:40:58 +0000

Hi Roni,
thanks again for these proposed changes.
see replies below, marked [acm]

@Alissa - these changes reply to your DISCUSS on places in
the memo where "RFC" appears, that should be generalized
(when using Specification Required policy).

Al

> publication of one or more immutable document such as an RFC)
[acm] 
ok, with s/document/documents/

> and major section number that specifies this”
[acm] 
ok

> URLs to referenced sections of HTML-ized reference document”
[acm] 
I went with 
The URL SHALL reference a target file that is HTML-formatted and contains 
URLs to referenced sections of HTML-ized RFCs, or other reference specifications.

> Note that In 7.2.1 talks about immutable document
[acm] 
I used immutable document in 7.2, instead of RFC.
> “for implementations referring to the immutable document text.”
[acm] 
ok

> Performance Metric-related documents,”
[acm] 
I don't think the Performance Metric Experts are in a position
to know about the universe of PM-related documents, just RFCs.
So I left this one as-is. We're talking about Expert Review here.

> immutable document, or the contact person.” Remove “or the contact person”
[acm] 
ok

> Section 11.2 change “including the RFC reference” to “including the
[acm] 
ok

---

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 11 Dec 2019 06:14:09 +0000

Hi Al,
I am OK with all the changes
Roni

> Sent: Wednesday, December 11, 2019 3:41 AM
> To: Roni Even (A); [email-masked]; [email-masked]; [email-masked]
> @Alissa - these changes reply to your DISCUSS on places in the memo where
> "RFC" appears, that should be generalized (when using Specification
> Required policy).
> 
> Al
> 
> > To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked];
> > last- [email-masked]
> > Section 3 bullet 1 has RFC change (up to and including the publication
> > of one or more RFCs or  I-Ds describing it) to (up to and including
> > the publication of one or more immutable document such as an RFC)
> [acm]
> > specifies this” to “Spec: an immutable document, for RFC the RFC
> > number and major section number that specifies this”
> [acm]
> ok
> 
> >
> >
> > Section 7.1.3 change “The URL SHALL reference a target file that is
> > HTML- formated and contains URLs to referenced sections of HTML-ized
> > RFCs” to “The URL SHALL reference a target file that is HTML-formated
> > and contains URLs to referenced sections of HTML-ized reference
> document”
> [acm]
> I went with