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

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

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 <[e-mail]>:
> 
> Hi, Mirja,
> 
> On Fri, Nov 9, 2018 at 10:59 PM Mirja Kuehlewind (IETF) <[e-mail]>
> wrote:
> 
>> 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.
>> 
> 
> 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
> 
> 
>> 
>>> 
>>>> 
>>>> 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