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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 29 Oct 2018 19:06:22 +0100

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: Thu, 1 Nov 2018 06:35:47 +0000

Thanks for your review, Mirja!

will resolve your comments ASAP,
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,
> 
> 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:
> 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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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=