Re: [ippm] AD review of draft-ietf-ippm-initial-registry-11

"MORTON, ALFRED C (AL)" <acm@research.att.com> Wed, 11 September 2019 20:35 UTC

Return-Path: <acm@research.att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71288120227; Wed, 11 Sep 2019 13:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0hHMhFzCXiJ; Wed, 11 Sep 2019 13:35:12 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B11A1207FF; Wed, 11 Sep 2019 13:35:12 -0700 (PDT)
Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x8BKQhTT019876; Wed, 11 Sep 2019 16:35:06 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049459.ppops.net-00191d01. with ESMTP id 2uy7v5gjw9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Sep 2019 16:35:05 -0400
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x8BKZ4WR037719; Wed, 11 Sep 2019 15:35:05 -0500
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x8BKYwoa037509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Sep 2019 15:35:01 -0500
Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id 9B034400B57D; Wed, 11 Sep 2019 20:34:58 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30499.vci.att.com (Service) with ESMTP id 707E7400B57A; Wed, 11 Sep 2019 20:34:58 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x8BKYwdk030043; Wed, 11 Sep 2019 15:34:58 -0500
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x8BKYmKf029372; Wed, 11 Sep 2019 15:34:52 -0500
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 57D2DE4AE8; Wed, 11 Sep 2019 16:34:00 -0400 (EDT)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Wed, 11 Sep 2019 16:34:44 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: "draft-ietf-ippm-initial-registry.all@ietf.org" <draft-ietf-ippm-initial-registry.all@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Michelle Cotton <michelle.cotton@iana.org>
Thread-Topic: AD review of draft-ietf-ippm-initial-registry-11
Thread-Index: AQHVXO7t1Dc8eia/wEeItN2FmjYM8qcgzyGQgAKIKoCAA63c4A==
Date: Wed, 11 Sep 2019 20:34:43 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA0AF690E@njmtexg5.research.att.com>
References: <40A0B71C-4857-46F0-9096-6EE289E7404B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CFA0AF4FA4@njmtexg5.research.att.com> <A8DB5ACD-7099-4642-B83C-E0C8A245C47B@kuehlewind.net>
In-Reply-To: <A8DB5ACD-7099-4642-B83C-E0C8A245C47B@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [69.141.203.172]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-11_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909110181
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/CuyR4KnSVoyJvTWzd9_-uxB2ncA>
Subject: Re: [ippm] AD review of draft-ietf-ippm-initial-registry-11
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2019 20:35:16 -0000

Hi Mirja,

I submitted -12, with secY updated for each name.
We're still waiting on Change controller advice, left as IETF.
Otherwise I think I've fixed all your points, but there 
are many ways to overlook them in a long memo, sorry if I did!

Al


> -----Original Message-----
> From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> Sent: Monday, September 9, 2019 4:18 AM
> To: MORTON, ALFRED C (AL) <acm@research.att.com>
> Cc: draft-ietf-ippm-initial-registry.all@ietf.org; IETF IPPM WG
> <ippm@ietf.org>rg>; Michelle Cotton <michelle.cotton@iana.org>
> Subject: Re: AD review of draft-ietf-ippm-initial-registry-11
> 
> Hi Al,
> 
> 
> See below.
> 
> > On 8. Sep 2019, at 18:35, MORTON, ALFRED C (AL) <acm@research.att.com>
> wrote:
> >
> > Hi Mirja,
> > I pressed SEND accidentally, even with wrong name, Sorry!
> > ("More coffee, please.") Continuing on reference topics.
> 
> No worries!
> 
> >
> > We've started the discussion on Intended Status,
> > so I'll start with the quicker questions and comments
> > on initial-registry draft below, on references topics.
> 
> Thanks!
> 
> >
> > Al
> >
> >> -----Original Message-----
> >> From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
> >> Sent: Tuesday, August 27, 2019 11:47 AM
> >> To: draft-ietf-ippm-initial-registry.all@ietf.org
> >> Cc: IETF IPPM WG <ippm@ietf.org>rg>; Michelle Cotton
> >> <michelle.cotton@iana.org>
> >> Subject: AD review of draft-ietf-ippm-initial-registry-11
> >>
> >> Hi authors, hi all,
> >>
> >> We need to discuss at least one bigger question on the intended status
> >> before we  can move ahead. However, as you can seen I have more
> >> questions/comments below.
> >>
> >> The bigger status question first:
> >> The intended status is PS. The shepherd write-up does not provide any
> >> additional information about why this status is appropriate. I would
> >> assume that informational is actually more appropriate. I don’t recall
> out
> >> of my head if/when this was discussed and I thought I rather ask than
> >> searching the list archive and minutes… Is this the right status and
> why?
> >> And if so, please reflect in the write-up!
> >>
> >>
> >> And then a couple more (hopefully) quicker comments/questions:
> >>
> >> - I know this was already reviewed by IANA (Michelle is also cc’ed),
> >> however, as far as I can see all Administrative Information (Status,
> >> Requestor, Revision, and Revision Date) and maybe even the ID don’t
> need
> >> to be part of the template because IANA will anyway assign them based
> on
> >> the instructions given in draft-ietf-ippm-metric-registry. Or did IANA
> >> explicitly request to also include these parts?
> > [acm]
> > I think Michelle and I were more comfortable that the
> > each section/template indicated exactly where IANA assignments
> > were needed. It's the line between the shared responsibility of Expert
> > Review and IANA to create a complete entry in the registry.
> 
> Okay.
> 
> >
> >>
> >> - Then for the Change Controller that should usually be the IESG rather
> >> than the IETF. Did IANA comment on that?
> > [acm]
> > Yes, this column is something IANA/Michelle asked for, and I think we
> > could be convinced that IESG could replace IETF. But to me,
> > "Standards Action" is IETF.
> 
> At least in the port registry we have the IESG as change controller. I was
> assuming that the “normal” practice… maybe Michelle can check that.
> 
> >
> >>
> >> - And one minor point: I guess the secY part of the name could already
> be
> >> filled out, no? However, I should probably have asked that on review of
> >> draft-ietf-ippm-metric-registry already but I was actually wondering if
> >> the decision to include the RFC number and section in the metric name
> is
> >> appropriate. Can you maybe lay out what the reasons for this are (and
> >> maybe also explain in the draft as his might come up again during IESG
> >> review otherwise)…?
> > [acm]
> > The reason is simple, a draft may specify more than one registry entry,
> > as -initial-registry does.
> >
> > I left the secY part general in case of changes during review.
> > It's very easy to fill this field at the end, when there is no
> > possible shuffling of section order that then requires name edits,
> > too.
> 
> Given we are basically “at the end" I recommend to fill it now.
> 
> >
> >>
> >>
> >> Then then on references again:
> >>
> >> - This draft references two obsoleted RFCs (RFC2679 and RFC2680). I
> assume
> >> this is an oversight and the references need to be updated?
> > [acm]
> > Yes, I need to use a text editor and globally update to 7679 and 7680,
> > XMLMind doesn't seem to let me search in the reference fields easily
> > (when viewing the XML source).
> 
> Good.
> 
> >
> >>
> >> - Also given you rely heavily on [Trammell-14], I think this needs to
> be a
> >> normative reference (and maybe [Strowes] as well?). The more stable
> >> pointer for [Trammell-14] is actually here:
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> >> 3A__link.springer.com_chapter_10.1007_978-2D3-2D642-2D54999-2D1-
> >> 5F2&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=hwJZg-
> >> IdxQ9507aw2mjEKKOSWIEVnc8nwr7B_QiOyCU&s=HSEAeC_uI-vofX5ZWPSCH-
> R4Ph8Gu618-
> >> YtZJ4pTAgE&e=
> >> But to be honest the split between normative and informational isn’t
> >> actually very clear to me here…?
> > [acm]
> > I welcome any advice on this too. If the reference is essential to
> > implementing the specification, then Normative, but I'm unsure about
> > making a publication Normative (as opposed to a standard).
> 
> I actually had the feeling it’s essential to implement correctly. Or
> alternatively maybe revise the text a bit. As long as your have a stable
> reference I think it can be normative. So I thought publications are
> fine...
> 
> >
> > I have fixed the pointer, we need it anyway, thanks for that.
> >
> >>
> >>
> >> And on the shepherd write-up:
> >>
> >> It’s indicated that not all authors have replied to the IPR question.
> This
> >> need to be checked and respectively reflected in the shepherd write-up
> >> before we can move ahead!
> > [acm]
> > If I can know who is missing, I can bug them.
> >
> >>
> >>
> >> And some smaller technical questions/nits:
> >>
> >> - Is it correct that T0 in section 4 is defined in both subsections
> 4.3.5
> >> and 4.4.2?
> > [acm]
> > It seems better to define T0 with the Run-time Parameters
> > and output reporting.
> > So deleted in 4.3.2 (Packet Stream Generation),
> > retained in 4.3.5 (Run-time) and 4.4.2 (output).
> > Same for section 5.
> 
> Good!
> 
> >
> >>
> >> - Why is an URI given (only) in section 6.1.3?
> > [acm]
> > This one avoided the deletion of all URNs, with the label URI...
> >
> >>  Also section 7.1.3 and 8.1.3.: http:\\www.iana.org\ ... <name> -> I
> >> think this should be: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.iana.org_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-
> e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=cP5fvDSvCv8R6d4wfrO1Cm0NBhxnC6MP3bDwAVWfjPg&s=lfu2JrEGk_CoNMtboZKJ
> U7Kc2lv475G7kQiuBXgze4M&e=
> > [acm]
> > just s/http/https/ AFAICT.
> > http was correct at some point in this draft's life, fixed both.
> 
> Good!
> 
> >>
> >>
> >> Some more editorial comments/nits:
> >>
> >> - I find it actually unnecessary or rather confusing that most (not
> all)
> >> sections start with a sentence/paragraph explaining what the section is
> >> about (e.g. "Additional (Informational) details for this entry”). I
> would
> >> think this is sufficiently explained in draft-ietf-ippm-metric-registry
> >> and does not need to be repeated here (in this already long document).
> >> Also note that section 8.6 inconsistently doesn’t have any content
> while
> >> 10.6. says “None.”.
> > [acm]
> > I anticipated that there are many approaches to writing
> > registry entries: one will be to simply copy an existing
> > entry and make changes (without ever reading the Registry
> > RFC). What we have mostly are instructions at the Category level,
> > and maybe a few cases of Column-level instructions that were
> > left behind after deleting most of them. When I see some text
> > inside < >, I'll take it out if it doesn't belong.
> 
> This is mostly a question of consistency as well. So please check. There
> is also text that is not in pointy brackets in some section, which was
> probably initially copied from the template and is not needed anymore (and
> got only removed in some sections but not others).
> 
> >
> >>
> >> - Also these comments in section 7 and 8 are probably supposed to be
> >> removed:
> >> " <insert name of the output type, raw or a selected summary
> statistic>”
> >> …?
> > [acm]
> > That's what I'm looking for, thanks.
> >
> >>
> >> - I found this in section 10.2.2: "@@@@@ others??”. I guess there is
> >> something missing? Also in this part, I don’t think SYN and FIN should
> be
> >> set at the same time, no? And rather than providing the Kind and Length
> of
> >> the TSopt, I would recommend to provide a pointer to the respective
> RFC.
> > [acm]
> > Yes, I've fixed all of this, thanks.
> 
> Thanks!
> 
> >
> > Please let me know if you want to see diffs with the
> > with the drafts and the current working text.
> 
> 
> No, just go ahead and submit a new version.
> 
> >
> > Brian had asked some shepherding questions,
> > nits and other. I just replied to him and fixed the
> > working text of -initial-registry.
> 
> Yes, thanks!
> 
> Mirja
> 
> 
> >
> >>
> >>
> >> 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? And what is expected to be on the URL page
> then?
> >> Wouldn’t it be necessary to also define a format for that page in order
> to
> >> be of any use?
> >>
> >>
> >> Mirja
> >>
> >>
> >>
> >>
> >