At the end ... ----- Original Message ----- From: "Jonathan Hardwick" <[email protected]> To: "t.petch" <[email protected]> Cc: <[email protected]>; <[email protected]> Sent: Monday, August 18, 2014 3:36 PM Subject: RE: [Pce] Regarding draft-ietf-pce-pcep-mib-09
Tom, many thanks for your comments. See [jon]... [/jon] inline below. Cheers Jon -----Original Message----- From: t.petch [mailto:[email protected]] Sent: 15 August 2014 12:33 To: Jonathan Hardwick Cc: [email protected]; [email protected] Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 Jon Picking up two of Adrian's points: - I would never have known the idea was to have multiple entities in a single 'box' modelled in the one MIB module - I think this unusual and while fine to do it, I would like to see it spelt out in s.4.1. It is often a source of confusion what an instance of an 'object class' actually is, which I think confused Adrian as well as me [jon] Agreed, I will spell it out more clearly as this has obviously caused some confusion. [/jon] - on the question of how many supported protocols, there used to be an enumeration " ipV4: PceRoutingDomainID is an InetAddressIPv4 .. ipV6: PceRoutingDomainID is an InetAddressIPv6 nsap: PceRoutingDomainID type is OCTET STRING (SIZE (0..20)), corresponding to the name of an ISIS area asNumber: PceRoutingDomainID type is OCTET STRING (SIZE (2)) corresponding to the name of an Autonomous System." but I assume that such concepts are long gone. [jon] Yes, the TC MIB has expired and is not needed by the current MIB. I don't think this TC was ever used by the PCEP MIB. [/jon] A trivial point of my own s/estbalished./established./ [jon] Thanks - will fix. [/jon] And does pcePcepSessState need to reflect the various contortions a shutdown can go through [jon] We decided to keep the states in line with RFC 5440 which does not specify any additional states during shutdown (the FSM goes straight to "idle"). It is possible that implementations may use intermediate shutdown states such as "quiescing" but I think these are probably best done in an implementation-specific field which modifies the "sessionUp" state. [/jon] , or all the various wait states of no interest? [jon] I think the wait states are useful. If a session is stuck not coming up, the operator will find it helpful to know if this is because the session is stuck in tcpPending, openWait or keepWait. [/jon] A sometime practice with other models of sessions is to keep information around for a while so that it is possible to tell what caused the shutdown. [jon] I think that the relevant information (which may be quite detailed) should be available in logs, and that logging interfaces would be better suited to it. Is it common to provide this type of thing in MIBs - can you point me to any examples? [/jon] <tp> Jon There are not that many session protocols to choose from in the IETF but TCP is richly endowed with information about its sessions, as in RFC4898 and RFC4022, but more humble protocols also tend to follow the practice, such as draft-ietf-forces-mib or RFC7331 (bfd). In the current climate, I expect that we should be grateful for anything in a MIB module:-( Tom Petch ----- Original Message ----- From: "Jonathan Hardwick" <[email protected]> To: "Dhruv Dhody" <[email protected]> Cc: <[email protected]>; <[email protected]> Sent: Thursday, August 14, 2014 12:27 PM Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09 <snip> _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
