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

["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. :-)

> 
> 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.

> 
> @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=