Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)
RFC 4165

Note: This ballot was opened for revision 13 and is now closed.

(Steven Bellovin) Discuss

Discuss (2004-09-10 for -)
There are a number of places (4.1.2 stands out) where there are SHOULDs that seem like they should be MUSTs.  There is no guidance on when one might not want to follow the advice.  For example, the draft says:

  It is necessary for at least one of the endpoints to be listening on
  the port on which the other endpoint is trying to establish the
  association. Therefore, at least one of the port numbers SHOULD be the
  M2PA registered port.

But that's the normal procedure for any client-server protocol.  Why is that specified explicitly here?  I agree that implementations can do things differently if they wish -- is there something more that I'm missing here?

4.1.2 says "it is RECOMMENDED that each endpoint know the IP address (or IP addresses, if multi-homing is used) and port number of both endpoints."  This needs to be clarified somewhat, in light of the text in [Security] -- each party MUST know the cryptographic identity of its authorized peers. This may or may not be an IP address. 

The assertion about professionally managed networks is, in fact, quite an assumption, and one that probably doesn't belong in this document.  What could be said, instead, is a list of conditions that, if true, could justify not turning on m2pa security.
Comment (2004-08-30 for -)
No email
send info
Except for this sentence:

        The description of how to use IPsec is inadequate.

my DISCUSS issues have not been addressed at all.  My DISCUSS stands.

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

Comment (2004-08-19 for -)
No email
send info
Reviewed by John Loughney, Gen-ART (both at -11 and -12).

His comment (excerpted):
I worked with the author to resolve the DISCUSSes on this.
I don't see any reason to hold this draft up any longer.

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

(Bert Wijnen) No Objection

Comment (2004-04-29 for -)
No email
send info
Missing IPR statements:
$ idnits <drafts/draft-ietf-sigtran-m2pa-11.txt
idnits 1.26, (21 Apr 2004)

 The document seems to use RFC 2026 boilerplate...
 The document seems to lack an 2026 Section 10.4(C) Copyright Notice
 The document seems to lack an RFC 2026 Section 10.4(C) Permission Grants Notice
 The document seems to lack an RFC 2026 Section 10.4(C) Disclaimer

(Alex Zinin) No Objection