MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-08

Thanks for addressing my DISCUSS.
Please make the link to draft-farbryantrel-mpls-retire-ach-tlv-00.txt 

Regards, Benoit

Thanks for addressing our concerns.

I have cleared under the premise that this extension is deployed in a highly controlled environment and that there is now  a textual warning about the possibility of congesting the link if not properly configured.

Thanks for the hash-to-MAC conversion!  Looks much better now.  One minor nit in Section 6.1:
OLD: "the following values MAY supported"
NEW: "the following values MAY be supported"


----Remaining initial comments-----

"""
   Upon receiving the second message, the receiver retains B-TLV1 from
   the first message and adds B-TLV7 to its B-database.
"""

This is the first mention of a "database", much less a per-application one, and there is no mention of databases anywhere else in the document, nor in RFC 5586.  It seems there's an architectural assumption that needs to be stated here.


"""
   Otherwise, the Value field specifies the applications for
   which an update is requested, in the form of a sequence of
   Application IDs:
"""

This might benefit from some clarity on responder behavior.  MAY the responder send a different list of apps?  MUST all requested apps be present in the response?


It would be nice to have a checksum-like mode for the Authentication Data, which provides some degree of integrity without a need for key management.  If you define the above application, you could also have a TLV that follows the same procedures as Authentication Data, but with a fixed set of parameters (HMAC function and key).

Agree with Richard's and Stephen's discusses.

Thanks for handling my discuss points.

(I still didn't go through the comments below but I know some of
'em have been addressed.)

- Only specifying how a sender sends but not saying what a
receiver does on receipt seems to result in a fairly incomplete
protocol.  I don't see that the usual "its MPLS, we manage these
devices" response works for that. This isn't a DISCUSS though
since I guess I could accept you saying "the receiver just puts
the TLV into a local database, but its seems fairly weak really.

- I assume that there are no congestion issues that are likely to
arise with the G-ACh due to the use of this protocol? 

- section 2: What does the first sentence of the last para of
section 2 mean? I can't parse it anyway.

- section 3, p6: "An error MAY be logged" - does that mean
locally or create some new n/w traffic? If the latter, isn't that
a potential DoS vector? 

- s3, p7: MI definition - how is MI expiry handled? You don't say
(here). If that uses the Lifetime from the application specific
body, then what if there are many of those?

- s3, p8: Why is an editor's note still present?

- s3, p8: Lifetime of 16 bits means max is ~18 hours. That seems
oddly short for configuration data for presumably heavily managed
links and liable to make implementation more complex since the
same stuff will have to be sent more than once every day. 

- s3, p8: The "source-channel-application tuple" seems ambiguous
to me - I guess you mean expires-at is the higher level
Timestamp+Lifetime, right? Why not say that?

- 4.1: can a source IP address represent a multicast group or
does it have to be "unique" to the sender?

- 4.2: this seems like a nice potential DoS vector too. (Say if
caculation of some TLV for which I ask consumes resources for the
sender of a GAP message containing that TLV.)

- 4.2: So length=0 means "send all" but app-id=0x0000 means
"who's there"? That seems clunky to me fwiw. I also don't get how
the last para of 4.2 is fully specified. 

- 5.1, Saying the MI is set at the "sender's discretion" seems
wrong, given you earlier said it has to be unique within some
(not that well) defined scope.

- 6.1: "secret string" - please don't say that as it  might be
interpreted to mean something human readable/memorable which
results in far weaker security. Please say "secret value" or
"secret octet string" and for bonus points say that if this is
human memorable then its basically pointless and that
implementations MUST be able to handle essentially random binary
values of the appropriate length.

- 6.3: Please refer to RFC2104 which is where HMAC is defined.
Following the bad practices from other RFCs that repeat the
definition is really not a good plan.

- I'd encourage you to say that use of GAP authentication is
RECOMMENDED?  That way, it may get used. Otherwise, I suspect
that it may be ignored, and we may be sorry about that later if
it turns out to just be another fig-leaf.