Hi Dhruv Thanks for the comments - see replies below (Jon> ...). I'll make sure these are addressed in the next revision.
Cheers Jon -----Original Message----- From: Pce [mailto:[email protected]] On Behalf Of Dhruv Dhody Sent: 31 July 2014 19:30 To: [email protected] Cc: [email protected] Subject: [Pce] Regarding draft-ietf-pce-pcep-mib-09 Hi Authors, I re-read the MIB document in preparation for the last call. You may consider these comments/nits before or alongside the WG last call. - General ~ Expand PCReq, PCRep, PCNtf, SVEC, RP etc on first use, using terminology Section may also be useful. Jon> OK. ~ PCEP speaker and PCEP entity are used interchangeably, perhaps we can unify? Jon> The aim is to use PCEP entity when referring specifically to a local entity (that is, one that appears in the pcePcepEntityTable) and PCEP speaker to refer more generally to any device that is speaking PCEP. I'll re-review and make sure there is consistency here. ~ a new object for corrupted messages (note that corrupted messages are different from unknown messages and this cannot be derived from number of error messages sent either). Jon> Happy to have this - please could you propose some text? - Abstract Add MIB as the abbreviation Jon> OK - Introduction Add TE as the abbreviation for Traffic Engineering Jon> OK - Shouldn't Section 3 'Requirements Language' about RFC2119 keywords be part of the introduction itself? Jon> This boilerplate text is usually in its own section in my experience. - Section 5.1 pcePcepEntityEntry OBJECT-TYPE SYNTAX PcePcepEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a PCEP entity." INDEX { pcePcepEntityIndex } ::= { pcePcepEntityTable 1 } ~ I think the description should not say 'this table' while describing an entry. Also true for pcePcepSessEntry. Jon> Not sure I understand - why? pcePcepEntityIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This index is used to uniquely identify the PCEP entity." ::= { pcePcepEntityEntry 1 } ~ Wouldnt Integer32 (1..2147483647) be a better fit? Jon> We are removing the range restriction instead. Suggest to reorder pcePcepEntityMaxKeepAliveTimer, pcePcepEntityMaxDeadTimer, pcePcepEntityAllowNegotiation, pcePcepEntityMinKeepAliveTimer, pcePcepEntityMinDeadTimer ~ by moving the pcePcepEntityAllowNegotiation first, you can use it in the description for both max and min timers. Jon> OK. pcePcepEntitySyncTimer OBJECT-TYPE SYNTAX Unsigned32 (1..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SYNC timer is used in the case of synchronized path computation request using the SVEC object... ~ Use SyncTimer (as used in 5440) instead of SYNC timer. Jon> OK pcePcepPeerNumSessSetupFail OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of PCEP sessions with the peer that have been attempted but failed before being fully estbalished. This counter is incremented each time a session with this peer fails before reaching session state pceSessionUp." ::= { pcePcepPeerEntry 8 } ~ the state is called sessionUp (refer pcePcepSessState) and not pceSessionUp Jon> OK - Security Considerations You might think of removing the text about SET operation, as this MIB is read-only. You might also add reference to SNMPv3 security like USM with AES as well to use of secure transport like SSH or TLS/DTLS. Jon> How about the following change (plagiarising text from RFC 6825): OLD It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). NEW Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Thank You! Dhruv _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
