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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Mirja wrote:
   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.

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

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> Sent: Friday, November 9, 2018 11:59 PM
> To: MORTON, ALFRED C (AL) <[e-mail]>
> Cc: [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 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]
> > 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=
> >