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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Al,

see inline.

> Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) <[e-mail]>:
> 
> Hi Mirja, and Spencer,
> 
> replies below, with a question for the "Outgoing AD"
> Al
> 
>> -----Original Message-----
>> From: Mirja Kuehlewind (IETF) [mailto:[e-mail]]
>> Sent: Friday, November 9, 2018 9:22 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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. :-)

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.

> 
>> 
>> Also looking at the references again, I think RFC6335 does not need to be
>> a normative reference.
> [acm] 
> 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


> 
>> 
>> @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.
> 
>> 
>> Mirja
>> 
>> 
>>> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL)
>> <[e-mail]>:
>>> 
>>> Hi Mirja,
>>> please see replies in-line.
>>> Al
>>> 
>>>> -----Original Message-----
>>>> From: ippm [mailto:[e-mail]] On Behalf Of Mirja Kuehlewind
>>>> (IETF)
>>>> Sent: Monday, October 29, 2018 2:06 PM
>>>> To: [e-mail]
>>>> Cc: [e-mail]
>>>> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test
>>>> 
>>>> 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?
>>> [acm]
>>> yes, mentioned BBF TR-390 implementations as benefactors.
>>>> 
>>>> 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.
>>> [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.
>>> 
>>>> 
>>>> 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!
>>> [acm]
>>> Yes, please consider incorporating some of the details from
>>> my e-mail last August, 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.
>>> [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).
>>> 
>>>> 
>>>> 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.
>>> [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.
>>> 
>>>> 
>>>> 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.
>>> [acm]
>>> ok
>>> 
>>>> 
>>>> Thanks!
>>>> Mirja
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> ippm mailing list
>>>> [e-mail]
>>>> 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=
>