Pseudowire (PW) over MPLS PSN Management Information Base (MIB)
draft-ietf-pwe3-pw-mpls-mib-14

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

Lars Eggert No Objection

(Dan Romascanu; former steering group member) Yes

The comments are partiallybased on the MIB Doctor review performed by Orly Niklass

1. In the Security Considerations section: 

the pwMplsTable, pwMplsNonTeMappingTable and pwMplsTeMappingTable
      collectively contain objects to provision PW over MPLS tunnels.
      Unauthorized access to objects in these tables, could result in
      disruption of traffic on the network.  The use of stronger
      mechanisms such as SNMPv3 security should be considered where
      possible.  Specifically, SNMPv3 VACM and USM MUST be used with any
      v3 agent which implements this MIB module.  Administrators should
      consider whether read access to these objects should be allowed,
      since read access may be undesirable under certain circumstances.

Two problems here: 
- the security threat resulting from intentionalor unintentional mis-configuration of the obects in the pwMplsTable, pwMplsNonTeMappingTable and pwMplsTeMappingTable should be explicitly stated, as the consequences may be partial or total loss of service for customers connected through the PW which is more than just disruption of traffic. 
- The should in the second phrase SHOULD be capitalized

2. 

OLD

that are common to all types of emulated services and PSNs.  This
layer is connected to the service-specific layer above, and the PSN
layer below.                                               ^

 

NEW:

that are common to all types of emulated services and PSNs.  This
layer is connected to the service-specific layer above, and to the PSN
layer below.
 

3) 

  'single hop there is an MPLS tunnel - even though the actual packet'
                                                 
Why do we have the dash?

 
4) 

OLD: there is

-- conformance information
 
       pwMplsGroups      OBJECT IDENTIFIER ::= { pwMplsConformance 1 }
       pwMplsCompliances OBJECT IDENTIFIER ::= { pwMplsConformance 2 }
 

Normally (as listed in RFC4181) we order then with
    Compliances first and then Groups. 
       xxxMIB
       |
       +-- xxxNotifications(0)
       +-- xxxObjects(1)
       +-- xxxConformance(2)
           |
           +-- xxxCompliances(1)
           +-- xxxGroups(2)

(Mark Townsley; former steering group member) Yes

(Chris Newman; former steering group member) No Objection

(Cullen Jennings; former steering group member) No Objection

(David Ward; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Jon Peterson; former steering group member) No Objection

(Lisa Dusseault; former steering group member) No Objection

(Magnus Westerlund; former steering group member) No Objection

(Pasi Eronen; former steering group member) No Objection

Editorial nits from Stephen Hanna's SecDir review:
In section 6, the word "require" in the third bullet should be
"required". Later in that bullet, "pwMplsTeOutbaoundTable" should be
"pwMplsTeOutboundTable" (remove an 'a').  In the first paragraph of
section 7, "pwTbale" should be "pwTable".

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

  Please remove the following before publication as an RFC:
  >
  > Comments should be made directly to the PWE3 mailing list at
  > pwe3@ietf.org.

  Please expand "PSN" the first time it is used.

  Section 7: s/pwTbale/pwTable/

(Tim Polk; former steering group member) No Objection