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; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2004-09-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Jon Peterson; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Allison Mankin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection (2004-04-29 for -** No value found for 'p.get_dochistory.rev' **)
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

(Bill Fenner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Kessens; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection (2004-08-19 for -** No value found for 'p.get_dochistory.rev' **)
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; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sam Hartman; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Scott Hollenbeck; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ted Hardie; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Thomas Narten; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info