Subject: tsv-dir review of draft-ietf-tsvwg-iana-ports-09

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 19 Jan 2011 14:54:18 -0600

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

This draft is ready for publication as a BCP RFC.

A few small comments which I don't think should be blocking are:

1 - on page 11, in section 6, "near-infinite" is a bit of an exaggeration

2 - on page 16, there's a typo: "MUST accompanied" should be "MUST be accompanied"

3 - on page 17, it may be a good idea to be clear whether the Assignee can be an individual (not just an organization)

4 - on page 17, Contact is defined as a person, but using the IESG as the Contact makes it a group (not a "person"); it might be good to clarify Contact as a person or group of people

5 - on page 17, in the Reference definition, it may be good to qualify the description of broadcast/multicast/anycast use by the protocol as being IP-layer broadcast/multicast/anycast to disambiguate from possible application-layer mechanisms for these that might be used

--
Wes Eddy
MTI Systems

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Jan 2011 13:12:57 +0200

Hi,

I'm updating the working copy in response to the LC reviews. See below for how I'm addressing things.

> 1 - on page 11, in section 6, "near-infinite" is a bit of an exaggeration

Changed to "very many".

> 2 - on page 16, there's a typo: "MUST accompanied" should be "MUST be accompanied"

Was already fixed in our working copy.

> 3 - on page 17, it may be a good idea to be clear whether the Assignee can be an individual (not just an organization)

Fixed. (Alexey had commented on that, too.)

> 4 - on page 17, Contact is defined as a person, but using the IESG as the Contact makes it a group (not a "person"); it might be good to clarify Contact as a person or group of people

I actually think we want the contact to be *one* person. I propose to fix this by making the IETF Chair the contact person for IETF registrations assigned to the IESG.

> 5 - on page 17, in the Reference definition, it may be good to qualify the description of broadcast/multicast/anycast use by the protocol as being IP-layer broadcast/multicast/anycast to disambigua…

Fixed.

Thanks,
Lars