TSVDIR review of draft-ietf-mboned-addrarch-07

[Joe Touch <[e-mail]>]

Hi, all,

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
[e-mail] if you reply to or forward this review.

The document describes the various mechanisms for IP multicast address
allocation (delegating a group of addresses for further assignment) and 
assigment (assigning addresses for use). The document currently 
addresses no transport issues.

There is one notably missing transport issue that should be addressed 
prior to publication. The document discusses the use of specific 
multicast addresses by individual applications, but does not currently 
address the relationship of multicast addresses to transport identifiers 
(e.g., port numbers or service names).

The note below includes the significant transport issues, as well as
additional comments that are optional but I hope also useful.

I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.

Joe

--------------------------------------------------------------

Transport issues include:

- sec 2.4 currently discusses use of multicast by applications
Sec 3.4.1 especially should discuss the relationship between multicast 
addresses and transport identifiers for per-application use, and when 
each (or both) are useful. E.g., sharing a multicast address reduces 
network state, but prevents optimizing distribution trees per service.
Sharing a multicast address (e.g., if one were assigned to "all 
backups", as one is currently assigned for "all routers") could reduce 
the need for per-application multicast addresses, but requires 
coordinated transport identifiers (e.g., assigned ports). Using 
multicast addresses as transport identifiers could obviates the need for 
a globally-assigned port number.

- the discussion in sec 3.4.1 needs revision
The discussion should focus on facts, rather than stating the facts 
inside judgements (e.g., remove 'lucrative', and 'land grab'). The facts 
appear to be that they're global and limited, and that self-assignments 
can conflict with IANA assignments; this is no different from the port 
numbers space. The key issue is that the appropriate spaces are much 
smaller (8-bits in the Internetwork block, but 24 bits in the admin 
scoped block)

Sec 3.5 list item #2 is inconsistent with the discussion in sec 3.4.1
If IANA global assignments are the most common static assignments, then 
that should be indicated in sec 3.4.1. ]

This section should explain "last resort" as used in the tables in sec 
4, and whether that is expected to persist if admin scoped addrs are 
statically assigned

- sec 4.3 should discuss potential future resolution of the relationship 
between multicast addresses and transport identifiers in separating 
application traffic

-----------------------------------------------------------

Some other comments (hopefully optionally useful):

- the document moves RFC 2909 to historic
RFC 2909 was experimental; it's not clear it's necessary to move it to 
historic.

- it would be useful for the intro to explain why addresses are 
assigned, and what assignments are useful (e.g., in some cases, to speak 
to groups of devices, in others, for a service or application)

- the document should include some examples of current static 
assignments, e.g., 'all routers'

- sec 2.4 describes "*seriously* implemented"
This should be clarified as 'widely', 'robustly', or some other term 
that explains the deficiency.

- sec 2.4 discussion of Norton Ghost seems misplaced
It refers to an assignment issue, not an allocation one; it should be 
moved to somewhere in sec 3

- the tables in sec 4 use terms like "last resort" which are 
inconsistent with the discussion in previous sections (notably 3.4.1 
doesn't talk about that).

- the tables in sec 4 should indicate the size of the available space
e.g., total bits available, and typical allocation or assignment size 
(if known, or a range if appropriate). This would further assist those 
asking for addresses in determining the appropriate approach.

Further, these tables could be expanded to summarize info already 
presented to further help those asking:
  	* replace "yes" with "self/dynamic/static" to differentiate
	  between (respectively) those internally calculated, those
	  obtained by a protocol exchange, and those obtained from IANA
	  or a registrar
	* explaining whether collisions can occur (or at least are
	  prevented by assignment/protocol)
	* indicate which multicast block is assigned/allocated using
	  the given mechanism

- sec 5 first paragraph wording would benefit from revision
E.g., starting with "This work was inspired and movtivated by ..."; the 
current text doesn't parse as a complete sentence.

----