Review of draft-ietf-mpls-gach-adv-02

(Sorry this is a day light.  Messy travel schedule.)
This document is clear, concise, and useful.
However, I do have some comments and questions.

The TLV structure is carefully laid out so that the Length is on a 16 
bit boundary, and the whole thing can be processed on 32 bit boundaries. 
  However, there is no requirement for padding or alignment on TLVs.  As 
such, implementations must allow for someone defining a TLV that takes 
an odd number of bytes, thus apparently removing all the advantage of 
the alignment care.

What is the point of the Message Identifier?  It is set by the sender as 
they please.  It is never sent back to the sender.  So the receiver can 
not do anything with it, since they have no idea how it was set.  And 
the sender can not do anything with it, since they sender never sees it 
again.  This field either needs more explaantion, or needs to be removed.

Section 4 on the G-ACh Advertisement Protocol TLVs starts by saying that 
the TLVS for the GAP protocol itself "represent metadata and processing 
instructions rather than static data that is meant to be retained."  But 
information like Source Address distinctly appears to be static data 
meant to be retained.  yes, it should be included in each GAP message. 
But it seems likely that the primary use of having the information would 
be based on retention / reuse.

In section 3, 4th paragraph, the text says
    The payload of a GAP message is an Application Data Block (ADB)
    consisting of one or more block elements.
But, the payload consists of a fixed header followed by the ADB.  Since 
this fixed header is not inherited from some other document, and is