Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Nov 2018 16:49:49 -0500

As long as TSV ADs are apologizing about this draft ...

https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/history/
shows pretty clearly that Some Guy Who's Not The AD For IPPM changed the
state from Publication Requested to AD Evaluation, which was no doubt a
surprise to at least some people who were more awake than Some Guy was,
that day

Your AD was, and remains, Mirja!

I can only offer as an excuse that what I did was once the right thing to
do for IPPM drafts, and I'll try to stop doing it now :-)

Spencer, as a participant, but one with AD privileges in the datatracker
(oh, my!)

On Mon, Oct 29, 2018 at 1:06 PM Mirja Kuehlewind (IETF) <[email-masked]>
wrote:

> Hi authors,
>
> first of all sorry for the rather long delay for this short draft. The bad
> news it that I probably have to delay the processing even further as I will
> not be able to join the next telechat on Nov 21 and we have to wait for the
> telechat on Dec 6. The good news is that gives us plenty of time for the
> IETF last call :-)
>
> I reviewed this document and I don’t think there are any issues that would
> not allow me to start the IETF last cal, but given we have time I would
> like to ask a few questions/comments:
>
> 1) The document gives plenty of background information and talks about
> impacts, however, it says very little about why it is good to have a fixed
> port, beside this:
> "It may simplify some operations to have a well-
>    known port available for the Test protocols, or for future
>    specifications involving TWAMP-Test to use this port as a default
>    port.“
> Is there any chance to say more than this?
>
> 2) Also, I agree with the shepherd that I don’t think it is necessary to
> detail the history as much as done in section 4, e.g. rather discuss the
> why than the actually comments by Lars and Tim. Also this section is called
> „definition“ but this background information seems to go beyond just
> defining something.
>
> Btw. Tianran, it would be nice if you could update your comments in the
> shepherd write-up accordingly if they have been addressed or are obsolete.
> Thanks!
>
> 3) I don’t think there is any normative language require in this doc. As
> you are „just“ stating what has been normatively defined in other
> documents, it is actually preferred to not re-state normatively.
>
> 4) An update in the registry does not necessary mean an „update“ of the
> RFCs that registered that ports in the first place, especially as rfc4656
> doesn’t even mention the UDP port at all. Of course the use of „update“ is
> very loosely defined and can be used if that is preferred but it is not
> strictly necessary. Or is there another reason to update these RFCs? If so,
> it should be clearly spelled out in the draft.
>
> 5) Given that these entries are updates it would be nice to also fill the
> missing information about contact information and assignee in the registry.
> Instruction for IANA would need to be added to the IANA section in this
> case. Assignee should be the IESG and contact the IETF chair. I assume the
> modification date will be filled by IANA respectively.
>
> Thanks!
> Mirja
>
>
>
>
>
>
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 4 Nov 2018 21:57:29 +0000

Hi Mirja,
please see replies in-line.
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind
> (IETF)
> Sent: Monday, October 29, 2018 2:06 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test
> 
> Hi authors,
> 
> news it that I probably have to delay the processing even further as I
> will not be able to join the next telechat on Nov 21 and we have to wait
> for the telechat on Dec 6. The good news is that gives us plenty of time
> for the IETF last call :-)
> 
[acm] 
yes, mentioned BBF TR-390 implementations as benefactors. 
> why than the actually comments by Lars and Tim. Also this section is
> called „definition“ but this background information seems to go beyond
> just defining something.
[acm] 
Ok the section is now titled, Definitions and Background,
and most of the details describing comments from Lars and Tim
are moved to an Appendix A.

> shepherd write-up accordingly if they have been addressed or are obsolete.
[acm] 
Yes, please consider incorporating some of the details from
my e-mail last August, thanks!

> documents, it is actually preferred to not re-state normatively.
[acm] 
The Scope says: 
	The scope of this memo is to re-allocate well-known ports for the UDP 
	Test protocols that compose necessary parts of their respective 
	standards track protocols, OWAMP and TWAMP, along with clarifications 
	of the complete protocol composition for the industry.

The controversy about TWAMP composition is partly what brought us here!
We used the term REQUIRED in the Definitions to resolve the small ambiguity
created when OWAMP authors did not use normative language when describing
the protocols that comprise OWAMP, and TWAMP authors followed that choice of
wording (unfortunately).
  
> strictly necessary. Or is there another reason to update these RFCs? If
> so, it should be clearly spelled out in the draft.
[acm] 
Ok, drawing on the point from the Scope, and requirement Language above,
the Abstract now ends with:

The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-known port 
assignments, and clarifies the complete OWAMP and TWAMP protocol composition 
for the industry.

> missing information about contact information and assignee in the
> registry. Instruction for IANA would need to be added to the IANA section
> in this case. Assignee should be the IESG and contact the IETF chair. I
> assume the modification date will be filled by IANA respectively.
[acm] 
ok

> 
> Thanks!
> Mirja
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fczRvYcfFcuwftALPl3iddxBqrOCp
> UTLa2qfPshPmRY&s=D-D42Pu3DFr7TAIb4ras87t2cNxyDt4UURtFGkPZDOo&e=

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 10 Nov 2018 09:21:46 +0700

Hi all,

sorry one more question: RFC7594 would be a downref and I think it is correct that this is a normative reference because it pointed to in the security sec. On the other it seems a bit weird to point normatively to the security section of an informational doc. So just double-checking if that is all right (given downrefs need to be called out in the last call, so we have to decide before I start last call)? 

Also looking at the references again, I think RFC6335 does not need to be a normative reference.

@Tianran: a downref is a normative reference to a document with a lower maturity level, so also a normative reference from a draft that is intended for Proposed Standard to an informational RFC is a downref. In the shepherd write-up you only say that there are normative reference to RFCs, however, you would next time also need to check the status of these RFCs. Thanks! Btw. could you please update the shepherd write-up?

Mirja

> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL) <[email-masked]>:
> 
> Hi Mirja,

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 10 Nov 2018 03:47:54 +0000

Hi Mirja, and Spencer,

replies below, with a question for the "Outgoing AD"
Al

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Friday, November 9, 2018 9:22 PM
> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test
> 
> Hi all,
> 
> sorry one more question: RFC7594 would be a downref and I think it is
> correct that this is a normative reference because it pointed to in the
> security sec. On the other it seems a bit weird to point normatively to
> the security section of an informational doc. So just double-checking if
> that is all right (given downrefs need to be called out in the last call,
> so we have to decide before I start last call)?
[acm] 

Yes, I'd like to keep the Downref, and also ask to place RFC 7594
on the "permanent Downref exception list". I don't know the exact
name of this list, but the IPPM Framework RFC 2330 was placed on it.

@Spencer: "Outgoing AD" may be able to help us find the list above,
before you go please. :-)

> Also looking at the references again, I think RFC6335 does not need to be
[acm] 
If our colleagues in IANA are ok with that, so am I.

> 
> @Tianran: a downref is a normative reference to a document with a lower
> maturity level, so also a normative reference from a draft that is
> intended for Proposed Standard to an informational RFC is a downref. In
> the shepherd write-up you only say that there are normative reference to
> RFCs, however, you would next time also need to check the status of these
> RFCs. Thanks! Btw. could you please update the shepherd write-up?
[acm] 
+1, thanks Tianran.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 10 Nov 2018 11:59:01 +0700

Hi Al,

see inline.

> Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) <[email-masked]>:
> 
> Hi Mirja, and Spencer,
> 

It’s called Downref registry and it's here:

https://datatracker.ietf.org/doc/downref/

My understanding is that it will go there automatically if once referenced as a downref but I can double-check during the publication process.

> If our colleagues in IANA are ok with that, so am I.

Okay. Actually we can do this later and don’t have to do it before last call, which I will respectively start now.

Thanks!
Mirja

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 10 Nov 2018 05:12:47 +0000

Mirja wrote:

   My understanding is that it will go there automatically 
   if once referenced as a downref but I can double-check 
   during the publication process.

I believe we need to make a specific request for inclusion
of RFC7594 (because I think we've already been down the 
"Downref road" for 7594, at least LMAP has). This will 
come-up repeatedly, and it's worth any extra steps IMO.

thanks Mirja!
Al

> Sent: Friday, November 9, 2018 11:59 PM
> To: MORTON, ALFRED C (AL) <[email-masked]>
> Cc: [email-masked];
> [email-masked]; [email-masked]
> 3A__datatracker.ietf.org_doc_downref_&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=-
> 2gjXWN8GSCH2I3PCN4fQ5jyDn_86Nn1_deP7q0CqEg&s=cZzpWhZWLQvFArAhIg4-
> xhQhpyQnELhBfagtUfaTjTU&e=
> 
> My understanding is that it will go there automatically if once referenced
> as a downref but I can double-check during the publication process.
> 
> >
> >>
> >> Also looking at the references again, I think RFC6335 does not need to
> be
> >> a normative reference.
> > [acm]
> Okay. Actually we can do this later and don’t have to do it before last
> call, which I will respectively start now.
> 
> Thanks!
> Mirja
> 
> 
> >
> >>
> >>>> first of all sorry for the rather long delay for this short draft.
> The
> >> bad
> >>>> doesn’t even mention the UDP port at all. Of course the use of
> „update“
> >> is

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 10 Nov 2018 12:15:08 +0700

Okay, I’ll check!

> Am 10.11.2018 um 12:12 schrieb MORTON, ALFRED C (AL) <[email-masked]>:
> 
> Mirja wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Nov 2018 09:35:29 -0600

Hi, Mirja,

> as a downref but I can double-check during the publication process.

Right, on the location.

I can't verify whether downrefs are automatically added or not now, but I
THOUGHT that the idea is that a downref to (say) Informational RFC F00
might be OK for draft A, but not for draft B, so this wasn't intended to
happen automatically.

If we think the downrefs to RFC F00 will always be good enough, no matter
what the referring document is, we would add the reference to the downref
registry.

Spencer

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 14 Nov 2018 23:31:55 +0700

Spencer, you are right! I’ll check what the process is when I’m back!

> Am 14.11.2018 um 22:35 schrieb Spencer Dawkins at IETF <[email-masked]>:
> 
> Hi, Mirja,
> 
>>>>>> in this case. Assignee should be the IESG and contact the IETF chair