Re: [OPSAWG] Red: RFC8907 (was: Re: Can we please adopt draft-tuexen-opsawg-pcapng?)
+1 /js On Fri, Nov 13, 2020 at 07:18:38AM +0100, Eliot Lear wrote: > We need to back away from using bureaucratic process that will chase away > developers for no good reason. Do you think Guy Harris has the time or > inclination to do this twice for no good reason? > > Even broken as it was, TACACS+ was NOT an ISE document. Neither was JSON. > There is NO precedent for a spec we want to move forward as an IETF spec to > go through the ISE. If it’s within this group’s purview, we should take it. > The ISE is a relief valve, not a go to. We would be misusing that process, > and I would likely object to doing so. > > If people insist that the document should be informational, fine, but even > that is a lie. This is an evolving de facto standard, and not recognizing it > as de jure seems silly. Worse, by forcing people down this road, we are > doubling the amount of work to get to a proposed standard. And for what? Do > we really think we’re going to change that much even in that process? > Looking back it was even silly for JSON to have gone through informational. > It was a waste of everyone’s time. The final stage was what was important, > and the mods were modest. > > TACACS+ was different. The IETF would not have endorsed TACACS+ in its > current form, but having it written was important for both implementors and > deployments to understand what they were seeing a lot of on the wire. > > Recognize why the rules exist and use them appropriately. This should go > forward as a PS candidate. > > Eliot > > > On 13 Nov 2020, at 01:54, Michael Richardson > <mailto:mcr+i...@sandelman.ca>> wrote: > > > > Signed PGP part > > > > Alan DeKok mailto:al...@deployingradius.com>> > > wrote: > >>> (or who read THEDRAFT), but i remember older RFCs that clearly state when > >>> a protocol > >>> is a proprietary vendor protocol not developed by the IETF. I think this > >>> RFC should > >>> have done it too for clarity. BY not writing it clearly, it looks like a > >>> particular > >>> vendor endorsement by IETF in an inappropriate fashion. > > > >> That's a reasonable point. But the doc is "Informational", and the > >> protocol has a 20+ year history. So it's pretty clear where it came > >> from. And, that documentation does not imply endorsement. > > > > Hi, so PCAPNG does not have a 20+ year history. More like 6-8 year. > > *PCAP* does have ~30 year history. > > > > MORTON, ALFRED C (AL) > <mailto:a...@research.att.com>> wrote: > >> I have a suggestion: the pcapng work proposal goes forward as *two > >> drafts*: > > > >> 1. a draft intended as an Independent Submission RFC to describe > >> pcapng/2010 *as-is*. > > > > That would be draft-gharris-opsawg-pcap-00, and I will bring it to ISE. > > If this WG would prefer to adopt is as a set, that's fine with me. > > There are IANA Registries that could move around. > > > >> 2. a proposal for a WG draft, to collect all the new/good ideas while > >> (probably) maintaining backward compatibility with pcapng/2010 and the > >> utilities that read/write it. > > > > That would be draft-tuexen-opsawg-pcapng-02 > > > >> The WG helps prepare *both* drafts, but when 1. is deemed complete and > >> accurate it heads off to the Independent Stream. > > > >> I have zero skin in this game, except that I capture packets whenever I > >> need to... > > > > I have this image of Cookie Monster. > > > > -- > > Michael Richardson mailto:mcr+i...@sandelman.ca>> > > . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
Toerless, I understand the benefits of formal definitions and tools reasonably well but assuming that everybody judges the benefits in the same way in every context is in my experience wishful thinking. (Look which problem ASN.1 tried to solve in the 1980s and how many data formats did come and go since then.) A standard, that is "better" than other solutions and at the end not implemented by key players, is a waste of time and energy. On the other hand, standardizing a format that is backed by existing deployed implementations in order to increase interoperability has a lot of practical value. I think we should welcome people that bring proposals backed by real-world and deployed implementations to the IETF. Standardizing pcapng has a clear value for me and I strongly support the effort. And I think we should trust that those who worked out the pcapng format and implemented it did take proper engineering decisions. It is fine to ask questions like 'did you consider X?' but it feels entirely wrong to tell them 'you should be doing X'. /js On Wed, Nov 11, 2020 at 09:49:59AM +0100, Toerless Eckert wrote: > I am sorry, but i don't think human parsing of ASCII diagrams to write code > for a protocol is appropriate for new designs anymore unless there are good > reasons. What are the good reasons ? > > Is this another case of ready developed code and the ask is "IETF bless it's > spec" ? Do we even know using any of the options (like CBOR) we have wouldnt > work ? > Not even having the discussion seems weird. I for once can't support this > work without having answers to those questions. Ideally written down in > the draft. > > We didn't invest all this effort into formal languages and standardized > encoding rules like CBOR to simply have them be ignored. And we're not asking > for considering their use because "that's what we do", but because of the > benefits > they bring to users and implementers: consistent cross-platform > implementation, > ability to drive code from spec and make exensibilities easier (and i > am sure i am forgetting other benefits). > > > Cheers > Toerless > > On Wed, Nov 11, 2020 at 09:08:17AM +0100, Juergen Schoenwaelder wrote: > > On Wed, Nov 11, 2020 at 03:22:18AM +0100, Toerless Eckert wrote: > > > On Wed, Nov 11, 2020 at 02:12:46AM +0100, Carsten Bormann wrote: > > > > On 2020-11-10, at 22:23, Toerless Eckert wrote: > > > > > > > > > > Why is the document not using a formal language to define the > > > > > syntax/semantic of its formatting ? Would CBOR/CDDL not be a > > > > > good candidate ? Any other ? > > > > > > > > Well, changing the format to be more regular (e.g., CBOR) is not what > > > > we want. > > > > > > Why not ? Its a new format, its meant to be easily extensible, verifyable, > > > etc. pp .. > > > > > > > Getting a better description might indeed be useful, but in the end > > > > that would have to describe all the warts of the current format, which > > > > is probably more than CDDL can do today (I haven???t checked, though). > > > > > > It seemed this doc was an ask for a new format. I agree that we > > > may not bother about better formal description of an old format. > > > > > > > It might be that they want the format they have written down and not > > CBOR or any other format out there. My experience with telling people > > they should use a "better" format, which is not the format they like > > to use in the first place, is that this leads to specs that are at the > > end not implemented and used. It is surely OK to point developers to > > possible alternatives so that they can take an informed decision but > > if developers then conclude that they prefer to use an ad-hoc format, > > it may be wise to accept this decision. The value of having an > > interoperable format is often higher than the value of making this > > format a well-known format (and taking the risk that at the end there > > is no interoperable format). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > -- > --- > t...@cs.fau.de > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
On Wed, Nov 11, 2020 at 03:22:18AM +0100, Toerless Eckert wrote: > On Wed, Nov 11, 2020 at 02:12:46AM +0100, Carsten Bormann wrote: > > On 2020-11-10, at 22:23, Toerless Eckert wrote: > > > > > > Why is the document not using a formal language to define the > > > syntax/semantic of its formatting ? Would CBOR/CDDL not be a > > > good candidate ? Any other ? > > > > Well, changing the format to be more regular (e.g., CBOR) is not what we > > want. > > Why not ? Its a new format, its meant to be easily extensible, verifyable, > etc. pp .. > > > Getting a better description might indeed be useful, but in the end that > > would have to describe all the warts of the current format, which is > > probably more than CDDL can do today (I haven???t checked, though). > > It seemed this doc was an ask for a new format. I agree that we > may not bother about better formal description of an old format. > It might be that they want the format they have written down and not CBOR or any other format out there. My experience with telling people they should use a "better" format, which is not the format they like to use in the first place, is that this leads to specs that are at the end not implemented and used. It is surely OK to point developers to possible alternatives so that they can take an informed decision but if developers then conclude that they prefer to use an ad-hoc format, it may be wise to accept this decision. The value of having an interoperable format is often higher than the value of making this format a well-known format (and taking the risk that at the end there is no interoperable format). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WGLC for draft-opsawg-ntf
SNMPv3 (RFC 3411 etc.) become STD 62 about 18 years ago. This document specifically talks about SNMP version 1 and 2 (note that 'protocol version 2' is ambiguous, likely the authors mean version 2c). I wonder whether this is by intention (i.e., the authors want to make a point that SNMPv3 is not used) or whether this is an oversight. Note: I have _not_ reviewed this document, I only skimmed it and stumbled across this. /js On Thu, Sep 24, 2020 at 02:41:37AM +, Tianran Zhou wrote: > Hi WG, > > > > This email starts a working group last call for draft-opsawg-ntf. > https://datatracker.ietf.org/doc/draft-opsawg-ntf/ > > > > Please indicate your support or concern for this draft. If you are opposed to > the progression of the draft to RFC, please articulate your concern. If you > support it, please indicate that you have read the latest version and it is > ready for publication in your opinion. As always, review comments and nits > are welcome. > > > > The WG LC will end on 9st Oct 2020. > > > > Thanks, > > Tianran > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
Michael,
would an ICMP "administratively prohibited" not be a sufficient
signal? Sure, things can be made much more complex, but I doubt that
devices will try to actively investigate why they can't communicate
(and implement additional protocols for this) if all they can do at
the end is to change the color of an led or simply shut-off (i.e.,
stop assuming its a temporary network issue and reduce/stop probing
effort).
/js
On Tue, Jul 09, 2019 at 02:38:58PM -0400, Michael Richardson wrote:
>
> Eliot Lear wrote:
> > I’m not quite certain how it would work. Can you show a flow that will
> > work for an IoT device (e.g., headless and no display)?
>
> Device gets quarantined, and the MUD-controller moves it into an isolated
> "VLAN". I put air/scare quotes around VLAN, because it's a "MAC-address
> VLAN", not an 802.1Q thing. It's really just a layer-2 ACL.
>
> {We have no way to force the mishaving device into tagging it's packets, nor
> can we force it onto some other ESSID. We can't do a "port-based" VLAN,
> because wifi has no ports, and we don't really know how many unmanaged
> switches might be on the port anyway.
> One might map this onto a IEEE 802.1Q VLAN across a backbone}
>
> Instead of just dropping all traffic for a device in this category,
> all traffic (other than excepted traffic if you implement
> https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/)
> would go into a captive portal system.
>
> Such a system would, according to
> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
> receive a message when it initiates connections which are not allowed.
> (While the capport WG contemplated an ICMP unreachable message with a
> URI in it at one point, that is not the current design)
>
> Actually, I have no idea from reviewing the documentation what the
> appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT?
>
> Once the IoT device gets such a message, it can use the API
> described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> to retrieve a JSON object telling it that it is captive. At which point, it
> can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
> timer goes off. (%)
>
> This requires that the IoT device get the captive portal API end point, which
> https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can deliver
> via DHCPv4/v6 or RA.
>
>
> >> On 9 Jul 2019, at 16:41, Michael Richardson
> >> wrote:
> >>
> >> Signed PGP part
> >>
> >> Between editing drafts yesterday, I got to thinking about CAPPORT. I
> >> have been working on what to do when an IoT device violates it's MUD
> >> profile. There are a bunch of issues around this.
> >>
> >> Yesterday, it occured to me that when such a device is quarantined (I
> >> really think it should be "quaranteed", but that's not a word) that
> >> the capport controls and APIs should be available to the device to
> >> learn what went on.
> >>
> >> This is not new, I think that this as been the approach of most
> >> enterprise NEA systems upon encountering "infection". This has, I
> >> assume, involved forced HTTP proxies to inform human. But, if we have
> >> APIs, we can inform device as well.
> >>
> >> Is this on anyone's radar?
> >>
> >> --
> >> Michael Richardson , Sandelman Software Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >>
> >>
> >>
>
>
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG adoption poll for draft-song-opsawg-ntf
are defined. And I rather have clear definitions and not statements like 'something with characteristics defined somewhere in this document'. What about, say RFC 6291? Point to existing definitions. YANG clearly is not just a data modeling language for NETCONF anymore. I fail to understand Fig. 3. The idea that a MIB only covers objects of the management plane is somewhat surprising. If event reporting is part of the game, then, well, SNMP may still be part of deployed solutions. And syslog in practice often runs over UDP but UDP is not listed as a transport where syslog is mentioned. There are a number of these technical inconsistencies that need to be fixed. It seems some of the authors kind of use this document to refer to some of their other proposed works and this actually diminishes my excitement about this document. I suggest you limit yourself to standards or chartered work entertained by WGs or work that has significant industry traction. If this document comes across as an attempt to push the authors own ideas, it looses a bit of its credibility. There are a whole bunch of 'transmission' MIB modules covering lots of statistics about the different data transmission systems used by the data plane. I find it surprising that they are all pretty much ignored. Using simple counters for data plane data collection is to my understanding a requirement simply originating from the fact that things need to be done at line rate. Some of the data export will move from SNMP to other protocols, there is already MIB data export over IPFIX and you can translate MIB modules into YANG modules and use the YANG ecosystem using standardized mechanisms. The point I am making is that there are a ton of data models relevant for the data plane and they will continue to have value, whether the data is streamed is just a different way of accessing to the data and it does not imply that all data models have to be reinvented. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt
On Wed, Jan 24, 2018 at 11:05:13AM +0100, Eliot Lear wrote: > > In addition, I have received the following requests for data elements to > be added to the core model: > > * Manufacturer-Name > * Device-Type > * Model-Number > * Software-version > Will these definitions be aligned with definitions in 'ietf-hardware' defined in draft-ietf-netmod-entity-08.txt (which is in the state IESG Evaluation)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
address-pool will behave in the > NAPT mode + destination NAT > > and so on. As long as this is clear from the specification. One option you may consider is to use presence containers that can carry the bit when to enable / disable a specific NAT function. (Although personally, I am not such a big fan of presence containers, perhaps since I am not a fan of side effects in general). > > > [Med] Yes. > > > > > > > > > > > - logging-info > > > > > > > > Is this information complete? Perhaps it is for plain syslog > > > > (without any security) but I doubt the info is complete for the > > > > other transports mentioned, at least not for FTP. And surely, if you > > > > want to protect the logging information, then you will neeed way > > > > more parameters. And what does 'retrieving' logging entries mean? I > > > > assume with syslog and ipfix you push log messages. I am less sure > > > > about FTP. Perhaps less is more and simply provide support for > > > > syslog and leave the other options for extensions. You have a choice > > > > in place, so not need to go and deal with all possible complexity > > > > here. > > > > > > > > > > [Med] It is out of scope of specify the exact logging information. Those > > considerations are out of scope. We only focus on the protocol and the > > server information. > > > > I think my comment was saying that the information is not sufficient to > > talk to a server. > > [Med] It is only about the minimal set of information. The information is not > complete on purpose. Protocol-specific information is out of scope of this > document. I am not sure it is valuable to have a standards-track specification for something that is incomplete up the point that it can't be used if implemented without annotations and extensions, i.e., the whole thing can't be interoperable unless there is a standards-track extension. So I would rather not standardize this at all and wait until someone is willing to work out the details. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
is by design? > > [Med] Yes, the design was built with NAT/NAT64 as the core functionality. > Other specific-techniques are added as containers for clarity. > Hm. Perhaps a bit subtle without a description. > > Is this restricted to the acronyms that are used in the IANA > > protocol numbers registry? > > [Med] Yes. So please state this. > > - alg-name > > > > Is there a list of well-known ALG names? IANA? Or is this a random > > string that one needs to guess form the vendor's documentation, > > i.e., this is potentially not interoperable out of the box? Is there > > a way to obtain the number of ALGs supported or is the idea to do > > trial and error probing to find out (which is even harder if there > > are no well-known ALG names)? > > > > [Med] There is no "standardized/IANA" list of ALGs. There is a list of widely > deployed/implemented ones. > FWIW, we used to have this list: > > |+--rw ftp-alg-enable? boolean > |+--rw dns-alg-enable? boolean > |+--rw tftp-alg-enable? boolean > |+--rw msrpc-alg-enable?boolean > |+--rw netbios-alg-enable? boolean > |+--rw rcmd-alg-enable? boolean > |+--rw ldap-alg-enable? boolean > |+--rw sip-alg-enable? boolean > |+--rw rtsp-alg-enable? boolean > |+--rw h323-alg-enable? boolean > |+--rw all-algs-enable? boolean > > We changed the design to this one because it is easily extensible. Well, as long as it is clear what an ALG name is... > [Med] Yes. > > > > > - logging-info > > > > Is this information complete? Perhaps it is for plain syslog > > (without any security) but I doubt the info is complete for the > > other transports mentioned, at least not for FTP. And surely, if you > > want to protect the logging information, then you will neeed way > > more parameters. And what does 'retrieving' logging entries mean? I > > assume with syslog and ipfix you push log messages. I am less sure > > about FTP. Perhaps less is more and simply provide support for > > syslog and leave the other options for extensions. You have a choice > > in place, so not need to go and deal with all possible complexity > > here. > > > > [Med] It is out of scope of specify the exact logging information. Those > considerations are out of scope. We only focus on the protocol and the server > information. I think my comment was saying that the information is not sufficient to talk to a server. > I think it would help to be more specific > > about the security aspects of this data model. This text is quite > > generic. > > [Med] The text Acks that all information are sensitive. They must be > protected and secure means must be used. A generic statement - in the past you there usually was a problem getting such generic statements through the approval process since security people want authors to think through the security aspects of individual objects or groups of related objects. But you can try of course, perhaps the mindset has changed - and I am not a secdir reviewer. ;-) > With a NAT, things even have privacy aspects. If I can > > force a specific NAT mapping, I can track a subscriber. > > [Med] IMHO, this is not specific to the NAT. Mandating secure means to > control the NAT is a guard against such attack. I think this is actually more subtle than one might think but this is the job of the security directorate people to think about. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
t;
> - subscriber-mask-v6
>
> The name seems to indicate that this only applies to IPv6 prefixes
> handed out to CPEs. Perhaps this should be stated explicitely (but
> yes it is unlike to ever get an IPv4 prefix). But then, the
> subscriber-match has an IPv4 prefix example.
>
> - quota-type
>
> Is this a good name for the leaf? This seems to indicate for which
> transport protocol a port-limit is enforced. And this list is
> restricted to TCP, UDP, and ICMP while other parts of the model are
> more flexible in supporting additional transport protocols. So is it
> consistent to a rather restricted enum here?
>
> - port-set-timeout
>
> Needs a units statement.
>
> - timeouts
>
> Can I make the timeouts arbitrarily small, in the extreme case 0
> seconds? In some cases I find text like "for at least 6 seconds".
> Does this mean that the range is really uint32 { range "6..max"; }?
> Or is it still OK to configure the value 3 and the 'must' is really
> a 'should'?
>
> - port-timeout
>
> I doubt this is of type inet:port-number and there likely needs to
> be a units statement.
>
> - alg-name
>
> Is there a list of well-known ALG names? IANA? Or is this a random
> string that one needs to guess form the vendor's documentation,
> i.e., this is potentially not interoperable out of the box? Is there
> a way to obtain the number of ALGs supported or is the idea to do
> trial and error probing to find out (which is even harder if there
> are no well-known ALG names)?
>
> - all-algs-enable
>
> This says "Enable/disable all ALGs." but I _assume_ that I set this
> to false and to enable specific ALGs. Perhaps this interaction needs
> to be spelled out.
>
> - Is there any throttling mechanism needed in case my NAT is
> constantly operating around the notification thresholds?
>
> - Add units to the mapping limit definitions ("subscribers",
> "mappings", ...)
>
> - limit-per-subnet
>
> This is type inet:ip-prefix? I guess you wanted something else here.
>
> - Why are some limits mandatory, others not?
>
> - If you write 'limit per subscriber', how is a subscriber identified?
> I assume these are global per subscriber limits, i.e., all
> subscribers receive the same limit.
>
> - limit-per-subnet
>
> leaf limit-per-subnet {
> type inet:ip-prefix;
>
> description
> "Rate-limit the number of new mappings
> and sessions per subnet.";
> }
>
> I do not see how this works. The other limit-per-XXX objects are
> numbers - presumably defining the limit. This is a prefix?
>
> - logging-info
>
> Is this information complete? Perhaps it is for plain syslog
> (without any security) but I doubt the info is complete for the
> other transports mentioned, at least not for FTP. And surely, if you
> want to protect the logging information, then you will neeed way
> more parameters. And what does 'retrieving' logging entries mean? I
> assume with syslog and ipfix you push log messages. I am less sure
> about FTP. Perhaps less is more and simply provide support for
> syslog and leave the other options for extensions. You have a choice
> in place, so not need to go and deal with all possible complexity
> here.
>
> - For the statistics, we used to use plural form for counters back in
> SNMP land and I think this was good practice. So go with
> sent-packets, sent-bytes, rcvd-packets, rcvd-bytes, dropped-packets,
> dropped-bytes, ...
>
> - total-mappings, total-tcp-mappings, total-udp-mappings,
> total-icmp-mappings: These may use yang:gauge32.
>
> - address-allocated, address-free -> addresses-allocated, addresses-free
> (may also be yang:gauge32)
>
> - Some of these gauges might fluctuate fast (maybe consider
> exponentially smoothed gauges, but this might also be left for an
> extension).
>
> - The security considerations text should follow the new boilerplate
> that also covers RESTCONF. I think it would help to be more specific
> about the security aspects of this data model. This text is quite
> generic. With a NAT, things even have privacy aspects. If I can
> force a specific NAT mapping, I can track a subscriber.
>
> - At least one example has syntax errors. Examples should ideally be
> validated by tools so that the examples are syntactically correct and
> valid regarding the data model.
>
>
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
On Tue, Oct 24, 2017 at 06:43:21PM +0200, Eliot Lear wrote: > Giid evening Juergen, > > > On 10/24/17 5:51 PM, Juergen Schoenwaelder wrote: > > > > What you describe seem to be different policies. Are you saying that > > these different policies are bad or a huge management problem and > > hence we hard-code a default policy that is considered "good" in most > > situations? If you say removing the implied default rules results in a > > management burden, what is the reasoning? > > Here is a worst case scenario, Juergen: suppose you have 600 different > types of device on your network and each manufacturer has implemented > its own class for DNS support. That would mean that the network > administrator would essentially have to populate 600 classes. Better to > have a single class, given its commonality. There are very few such > common services on a network, but there are presumably one or two others > that will come to be, and thus the ability to extend this list over time. [...] > Make sense? Likely but I guess I have to do more reading to understand what 'populate classes' means for the network administrator... [. . . . ] Done some more reading. It is still unclear to me what 'populate classes' means. Some general comments (now that I read the ID): - s/only"accept"/only "accept"/ - the definition of tree diagrams is being moved from [I-D.ietf-netmod-rfc6087bis] to [I-D.ietf-netmod-yang-tree-diagrams] - I read: Great care should be used when invoking the controller class. For I am not sure what it means to invoke a controller class. So far, I thought that a 'controller class' is simply a set of IP addresses belonging to controllers. Hm. The other module abstracts away IP addresses into certain classes Controller: Devices that the local network administrator admits to the particular class. I guess I am confused by the usage of the word 'class'; the word seems to be used in different contexts with different meanings and hence I also confused what populate classes may mean. - Should the titles of 7.1 and 7.2 be changed to src-dnsname and dst-dnsname to align with the YANG definitions? Or should the text in 7.1 and 7.2 not simply become part of the description of src-dnsname and dst-dnsname? - Likely a wording issue: Four of "acl" liste entries that implement default MUD nodes is listed below. Did you mean: Four "acl" list entries that implement default MUD nodes are listed below. Back to the thread, which rule does appendix B with the 'default MUD nodes' really play? (a) Are these MUD rules that are assumed by a controller to be always there even if they are not? (b) Or are these a set of rules that manufacturers may include in their MUD files? I assume it is (a) but I find the text not entirely clear. The first sentence reads like these rules are automatically considered to be there (by the controller) but the second sentence says that a manufacturer can overwrite this if necessary. Well, the sentence are not explicit about which entity is doing what. [...] This is considered the default behavior and the ACEs are in effect appended to whatever other "ace" entries that a MUD file contains. To block DNS or NTP one repeats the matching statement but replaces the "forwarding" action "accept" with "drop". So why is (b) not workable and (a) required? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>g ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] MUD : ietf-acldns YANG model question.
May I ask what this warning is and where I find it? And yes, I am still
reading and learning so be patient with me.
/js
On Wed, Oct 25, 2017 at 05:01:50PM +0200, Eliot Lear wrote:
> I did add some text into the last draft explictly warning against this
> sort of construct.
>
> Eliot
>
>
> On 10/25/17 4:44 PM, M. Ranganathan wrote:
> > Hi Juergen, Einar,
> >
> > On Wed, Oct 25, 2017 at 10:30 AM, Juergen Schoenwaelder
> > <j.schoenwael...@jacobs-university.de
> > <mailto:j.schoenwael...@jacobs-university.de>> wrote:
> >
> > RFC 7858 defines DNS over TLS and this uses port 853 over TCP. ;-)
> > It is generally risky to hard code things based on the assumption
> > that something never changes or is always needed.
> >
> > /js
> >
> >
> >
> > I just want to disallow the following:
> >
> >
> > "rule-name": "myctl0-todev",
> > "matches": {
> > "ietf-mud:mud-acl": {
> > "my-controller": [
> > null
> > ]
> > },
> > "ipv4-acl": {
> > "ietf-acldns:src-dnsname": "www.nist.gov
> > <http://www.nist.gov>",
> > "protocol": 6,
> > "source-port-range": {
> > "lower-port": 443,
> > "upper-port": 443
> > }
> > },
> > "tcp-acl": {
> > "ietf-mud:direction-initiated": "from-device"
> > }
> > },
> > "actions": {
> > "forwarding": "accept"
> > }
> >
> >
> > It is possible to express this as two separate ACL entries. I believe
> > the current YANG model would accept this.
> >
> >
> >
> > On Wed, Oct 25, 2017 at 02:23:09PM +, Einar Nilsen-Nygaard
> > (einarnn) wrote:
> > > Technically, you could express both of these constraints.
> > >
> > > But why would we want to do this? One developer’s clarity may be
> > another’s verbosity, and what if someone actually does want to
> > drop certain DNS requests?
> >
> >
> > The working model in MUD is to implicitly DENY any communication that
> > is not expressly allowed. It seems redundant to start with this
> > working assumption and then allow DENY rules anyway.
> >
> >
> > Thanks,
> >
> > Ranga.
> >
> >
> >
> > >
> > > Cheers,
> > >
> > > Einar
> > >
> >
> >
> > --
> > Juergen Schoenwaelder Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587>
> > Campus Ring 1 | 28759 Bremen | Germany
> > Fax: +49 421 200 3103 <tel:%2B49%20421%20200%203103>
> > <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> >
> >
> >
> >
> > --
> > M. Ranganathan
> >
> >
> > ___
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] MUD : ietf-acldns YANG model question.
RFC 7858 defines DNS over TLS and this uses port 853 over TCP. ;-) It is generally risky to hard code things based on the assumption that something never changes or is always needed. /js On Wed, Oct 25, 2017 at 02:23:09PM +, Einar Nilsen-Nygaard (einarnn) wrote: > Technically, you could express both of these constraints. > > But why would we want to do this? One developer’s clarity may be another’s > verbosity, and what if someone actually does want to drop certain DNS > requests? > > Cheers, > > Einar > > > On 25 Oct 2017, at 14:39, M. Ranganathan <mra...@gmail.com> wrote: > > > > Is it possible to modify the YANG model for ietf-acldns to explicitly > > disallow "drop" ACE rules? > > (i.e. only "forwarding":"accept" } not knowledgeable enough about YANG to > > suggest the change). > > > > It would also be convenient if there were a way to disallow both > > controllers AND hostnames in a single ACL entry (for reasons of clarity) > > but again I don't know how to state that in YANG. > > > > Thanks, > > > > > > > > -- > > M. Ranganathan > > ___ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
On Tue, Oct 24, 2017 at 05:23:34PM +0200, Eliot Lear wrote: > > -- There is default behavior associated with those classes. ( For > > example, you talk to DNS on port 53, NTP on port 123.) If a MUD rule > > specifies nothing (no ACEs) then these two classes exist invisibly as > > ALLOW rules. > > Yes. Invisible = default. The key point is that if we don't do this > then most vendors will end up doing their own thing, and this becomes a > management burden, and some are surely going to get them wrong, for that > matter. [...] > > - The manufacturer can disable his device talking to dns and ntp > > services altogether by specifying DENY rules. Why specify a default > > behavior and multiple ways to override the default when the presumed > > reason is to save a few lines in the ACL file. > > > That's not the sole reason. There are multiple ways to implement these > rules, and it is best to have a single consistent way. So for instance, > one could implement them as permitting communication to ALL devices on > UDP port 53. One could implement them by stating that the name server > be admitted as "my-controller" on port 53. One could create a > vendor-specific controller class such as > "https://vendor.example.com/resolvers; and permit that class on port > 53. And the challenge is that that class has to then be somehow > resolved. Better to have it as a default to simplify simple cases for > manufacturers and the network manager. Yes, this requires a bit of > extra code in the MUD controller, but as a design decision, we should > place the pain on ourselves. We can argue whether or not it is okay to > override this default– perhaps we shouldn't have that capability. But > certainly the default should be there. What you describe seem to be different policies. Are you saying that these different policies are bad or a huge management problem and hence we hard-code a default policy that is considered "good" in most situations? If you say removing the implied default rules results in a management burden, what is the reasoning? That having different rules for DNS (or NTP) would make debugging things more difficult? Given the vendors likely put creative and interesting rules into MUD files anyway, do two more rules matter? Would it be an option to have Appendix B an template that vendors SHOULD use if they want to allow access to DNS or NTP? Instead, of hardwiring it in the spec, we tell vendors that 'if you want to open up DNS and NTP, here is the suggested way to do this'. I am just trying to understand the reasoning for hardwiring two special cases. /js PS: Is there a logic how the rule names and acl names used in appendix B have been constructed? Does 'ent' mean something or is it a short form of 'entry'? Would v4-dns-in and v4-ntp-in be more descriptive than ent0-todev and ent1-todev and v4-dns-out and v4-ntp-out be more descriptive than ent0-frdev and ent1-frdev. Well, this might be to some extend subjective... -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG adoption poll for draft-sivakumar-yang-nat-07
I do not have a strong opinion whether this work should be done here or elsewhere. The key is to get the right people who are familiar with NAT implementations to review the technical content and to check whether the proposed model is implementable on different systems. >From a YANG perspective, the module should follow the NMDA guidelines (i.e., a merged config/state tree instead of two separate trees), see draft-dsdt-nmda-guidelines-01 for more details. For skimming the document, I am also concerned about |+--rw ftp-alg-enable? boolean |+--rw dns-alg-enable? boolean |+--rw tftp-alg-enable? boolean |+--rw msrpc-alg-enable?boolean |+--rw netbios-alg-enable? boolean |+--rw rcmd-alg-enable? boolean |+--rw ldap-alg-enable? boolean |+--rw sip-alg-enable? boolean |+--rw rtsp-alg-enable? boolean |+--rw h323-alg-enable? boolean |+--rw all-algs-enable? boolean which is somewhat verbose and does not look like an easily extensible design in case new ALGs are needed. Assuming that ALGs may need additional configuration or have additional state, perhaps the model should only provide the structure that can be augmented by ALG specific models instead of trying to list all ALGs out there. Perhaps it is OK to hardwire TCP and UDP but then we do have SCTP and DCCP in the IETF. Or at least think about how to factor them in if the need arises. Finally, make sure you use reference statements when you mention RFCs in description statements. Add unit statements where sensible. Concrete examples (that validate against the model) will help people to understand how to use the model in practice. (So please fill in section 4, consider moving it into the appendix since it is likely non-normative.) All this said, it seems like some substantial work has already gone into this document. I can't tell whether vendors will implement this but it would be for sure nice to have a common way to configure and monitor NATs. /js On Thu, Jul 27, 2017 at 10:09:14AM -0400, Joe Clarke wrote: > Greetings OPSAWG, > > After this draft was presented in Prague, it was stated that we would do a > call for adoption on the list. There seemed to be general support for the > work. Therefore, this will serve as the chairs’ formal adoption poll for > this document into OPSAWG. > > YANG Data Model for Network Address Translation (NAT) > https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/ > > This poll request will go for three weeks to allow for the summer vacation > time. Please get your feedback (and initial reviews) in by August 17, 2017. > > In addition to simply supporting the adoption, please also let us know if > you are willing to review the work as it progresses. > > Thank you. > > Joe (for the co-chairs) > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Errata Verified] RFC7666 (4710)
He? The fix aligns the textual description with the actual definition. What is your proposal? Keep them inconsistent? I am puzzled now as well. /js On Fri, Jun 17, 2016 at 07:15:03PM -0700, Randy Presuhn wrote: > Hi - > > I am puzzled that this change was permitted. > It seems to be in clear violation of the > constraints imposed by RFC 2579 section 5. > Once the textual convention has been published, > such a change, even if it is a "fix", is not > allowed by the interoperability rules. > > Randy > > -Original Message- > >From: RFC Errata System <rfc-edi...@rfc-editor.org> > >Sent: Jun 17, 2016 12:44 AM > >To: jm+i...@kubek.fr, pa...@hongo.wide.ad.jp, m...@vmware.com, > >j.schoenwael...@jacobs-university.de, keii...@iijlab.net, > >tina.tsou.zout...@huawei.com > >Cc: opsawg@ietf.org, i...@ietf.org, rfc-edi...@rfc-editor.org > >Subject: [OPSAWG] [Errata Verified] RFC7666 (4710) > > > >The following errata report has been verified for RFC7666, > >"Management Information Base for Virtual Machines Controlled by a > >Hypervisor". > > > >-- > >You may review the report below and at: > >http://www.rfc-editor.org/errata_search.php?rfc=7666=4710 > > > >-- > >Status: Verified > >Type: Editorial > > > >Reported by: jean-marie Kubek <jm+i...@kubek.fr> > >Date Reported: 2016-06-15 > >Verified by: Benoit Claise (IESG) > > > >Section: 6.2 IANA MIB > > > >Original Text > >- > >IANAStorageMediaType ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The media type of a storage device: > > > > unknown(1) The media type is unknown, e.g., because > > the implementation failed to obtain the > > media type from the hypervisor. > > > > other(2) The media type is other than those > > defined in this conversion. > > > >Corrected Text > >-- > >IANAStorageMediaType ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The media type of a storage device: > > > > other(1) The media type is other than those > >defined in this conversion. > > > > unknown(2) The media type is unknown, e.g., because > >the implementation failed to obtain the > >media type from the hypervisor. > > > > > >Notes > >- > >Inversion of other and unknown integer values in the description of the > >IANAStorageMediaType TEXTUAL-CONVENTION. > > > >FIrst referenced at IANA RT as [IANA #913286] Incoherency in > >IANA-STORAGE-MEDIA-TYPE-MIB > > > >-- > >RFC7666 (draft-ietf-opsawg-vmm-mib-04) > >-- > >Title : Management Information Base for Virtual Machines > >Controlled by a Hypervisor > >Publication Date: October 2015 > >Author(s) : H. Asai, M. MacFaden, J. Schoenwaelder, K. Shima, T. > >Tsou > >Category: PROPOSED STANDARD > >Source : Operations and Management Area Working Group > >Area: Operations and Management > >Stream : IETF > >Verifying Party : IESG > > > >___ > >OPSAWG mailing list > >OPSAWG@ietf.org > >https://www.ietf.org/mailman/listinfo/opsawg > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02
Keiichi, note that there is outdated text on page 9 that should be updated: The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. In the security considerations, I assume Dan wants: OLD There are two objects defined in this MIB, vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. NEW There are two objects defined in this MIB, vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have a MAX-ACCESS clause of read-write. Enabling notifications can lead to a noticeable number of notifications if many virtual machines change their state concurrently. Hence, such objects may be considered sensitive or vulnerable in some network environments. /js On Tue, May 26, 2015 at 07:23:17AM +, Romascanu, Dan (Dan) wrote: Hi, I would still recommend that you add text in the Security Considerations section in which you describe the risk of intentional or unintentional misconfiguration of the two writeable objects in the MIB module. It would also be useful to mention explicitly that the authors considered the risks of multiplication of notification and evaluated it as manageable for all reasonably designed and sized networks. Thanks and Regards, Dan -Original Message- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- university.de] Sent: Tuesday, May 26, 2015 9:47 AM To: Keiichi SHIMA Cc: Romascanu, Dan (Dan); draft-ietf-opsawg-vmm-mib@tools.ietf.org; ops-...@ietf.org; opsawg@ietf.org Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: Hi all, 17. I am concerned that the current way of defining the notifications switches is too course. Hypervisors may have many VMs in charge, and if each generates one notification per each state changes the numbers can become big even in normal operation. Maybe some throttling mechanism would be useful. Or maybe a couple of more switches that allow to enable only 'critical' notifications (e.g. vmCrashed). The only situation I can think of where the number of notifications will be significant is during restart of a whole rack with many hypervisors inside. But even then, things usually take time. (I think our Xen hypervisors actually create virtual machines sequentially and hence the notifications get actually spaced over time.) It is not unlikely that the operating systems inside the hypervisors during startup generate significantly more network traffic compared to a few hypervisor notifications. That said, during the development of the MIB module we moved from generic state change notifications to a set of specific notifications and this allows to use SNMPv3 notification filtering to filter out notifications people find not useful. I and Asai talked locally and we agree Juergen that the number of notification events is manageable. However we noticed that the 'vmBlocked' notification may be a problem. The 'blocked' state is defined as 'The operational state of the virtual machine indicating the execution of the virtual machine is currently blocked, e.g., waiting for some action of the hypervisor to finish. This is a transient state from/to other states.' This state transition event may appear more frequently than other events, since the state is caused by the I/O scheduler of the hyper visor implementation. We think we can simply remove the 'vmBlocked' notification. The 'blocked' state is a transient state and typically return to the previous state immediately (once the pending I/O requests completed). Yes, this makes sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs- 2Duniversity.de_d=AwIBAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31O cNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=MgxJDgRk1TpLrZ2hiPqtqSLH_gUN Xo4hIzz7Czjm6c0s=0FOhbeoR7FEAGZddNHtPDimJFq1MNfZlAEOjldkr1tAe = -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02
On Thu, May 14, 2015 at 04:45:19PM +, Romascanu, Dan (Dan) wrote: [...] Dan, many thanks for the review. I am skipping over the smaller nits. 16. Page 34-35: I have a big question mark about how the vmStorageReadLatency and vmStorageWriteLatency objects need to be used. First the usage of the Counter64 syntax seems odd as these objects do not count anything and their increase is not unitary. Second I do not know how to interpret them. What does say a reading of 'a million' or of 'a billion' mean? It really makes no sense if not interpreted in conjunction with the number of respective I/O operations, media type, etc. I guess that the implementation of these objects is not trivial and probably requires HW support taking into consideration the microseconds resolution. At a minimum I guess that some text recommending to the operators how they are supposed to be used is needed. The only SMIv2 requirement for a Counter64 is that it increases monotonically which is the case here. There is no requirement that a counter increases unitary. By making this a counter, it is clear that one has to to look at the first derivative, that is the change of the counter over time. Obviously, on a lightly loaded hypervisor, the latency should be small but in situations where it increases significantly, you are likely hitting a slowdown of your VMs due to I/O contention instead of CPU limits. These objects are there to identify such situations (and the virtual storage devices involved). 17. I am concerned that the current way of defining the notifications switches is too course. Hypervisors may have many VMs in charge, and if each generates one notification per each state changes the numbers can become big even in normal operation. Maybe some throttling mechanism would be useful. Or maybe a couple of more switches that allow to enable only 'critical' notifications (e.g. vmCrashed). The only situation I can think of where the number of notifications will be significant is during restart of a whole rack with many hypervisors inside. But even then, things usually take time. (I think our Xen hypervisors actually create virtual machines sequentially and hence the notifications get actually spaced over time.) It is not unlikely that the operating systems inside the hypervisors during startup generate significantly more network traffic compared to a few hypervisor notifications. That said, during the development of the MIB module we moved from generic state change notifications to a set of specific notifications and this allows to use SNMPv3 notification filtering to filter out notifications people find not useful. 18. The Security Considerations section does not include a description of the security hazards of mis-configuration of the writeable objects (danger of flooding the network with unwanted notifications) Perhaps text can be added but I am not sure I see that a data center network will experience any significant load due to these notifications. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch)
On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: [...] With YANG and netconf the configuration will be still vendor-specific and vendor-specific adjustments are still needed on site of the central Manager. This argument likely needs an explanation. There are people working quite hard towards standardized YANG models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [saag] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch)
I am confused by 'netconf server (Manager) and a networking device (netconf client = Analyzer)'. This is not how NETCONF usually works: A device runs a NETCONF server and a management application a NETCONF client. Anyway, the way things work with NETCONF and YANG is that you define a YANG data model that is understood by both the NETCONF server and the NETCONF client. I admit that I do not know much about your specific use case but if you make statements that sound like YANG models have to proprietary and hence IDPEF has an advantage because it is standardized, then you need to be able to defend that. /js On Sat, May 02, 2015 at 08:18:54PM +0200, B.-C. Boesch wrote: Hi Jürgen, netconf will be used between a netconf server (Manager) and a networking device (netconf client = Analyzer). IDPEF standardize the exchanged content so that no additional information is needed at the Manager to interpret the exchanged data. With IDPEF it is not relevant which vendors of Analyzers and Manager are combined. How could the Manager interpret the configuration data of the Analyzer without any additional information (e.g. MIB) in the YANG environment? How could I change options (e.g. thresholds) of an IDS signature of any IDS vendor with YANG without additional information on the netconf server? kind regards Björn-C. Am 02.05.2015 um 19:35 schrieb Juergen Schoenwaelder: On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: [...] With YANG and netconf the configuration will be still vendor-specific and vendor-specific adjustments are still needed on site of the central Manager. This argument likely needs an explanation. There are people working quite hard towards standardized YANG models. /js ___ saag mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/saag -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review.
On Mon, Mar 09, 2015 at 03:58:46PM +0100, Johannes Merkle wrote: I am not sure, how to resolve this comment. Please give advice. Juergen Schoenwaelder schrieb am 20.02.2015 um 17:49: - The comment behind LAST-UPDATED is wrong (this happens once there is redundant information) Shouldn't the dates specified in LAST-UPDATED and REVISION be the publication date of the RFC? In this case, I would need to add place holders with comments for the RFC Ed to replace them with the publication date. Or should these dates be set to the date when the MIB was finally prepared (neglecting editorial changes by the RFC Ed? Ideally it is the publication date (or more precisely the date when the final edits were made by the RFC Editor). They usually understand this for MIB modules but it never hurts to be explicit (and the check during AUTH48 as well). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Individual Draft: draft-mallette-opsawg-cabledevice-mib-00
On Mon, Mar 09, 2015 at 08:35:51PM +, Mallette, Edwin J. wrote: Greetings, I wanted to make you all aware of a individual draft that is intended to be an update to RFC4639 – Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems. As the original RFC is quite old, this draft is intended to provide an update to include the following: (1) updates to existing objects (2) updates to the compliance language WRT IPv4/IPv6 (3) alignment with additional CableLabs specifications that leverage the same MIB. I would appreciate any feedback and I intend (given a timeslot is made available) to talk about my draft in Dallas. I tried to run smidiff to see what changes have been made (and whether they are unproblematic wrt. SMIv2 update rules) but then it turned out that the proposed new MIB module has a number of syntax errors and I kind of gave up after fixing about five of them. Also the page header saying RFC 4639 and December 2006 can be confusing if you look at both versions in your editor. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review.
Hi, I have reviewed this document and I support it moving forward. There are a couple of nits that should be fixed before submitting the document to the IESG. Section 7.1: - replace MIB with MIB module Section 7.2: - replace The SNMP Management Architecture MIB (SNMP-FRAMEWORK-MIB) with SNMP-FRAMEWORK-MIB - remove Therefore, the use of the HMAC-SHA2 authentication protocols requires the usage of the objects defined in the SNMP-FRAMEWORK-MIB. since this sentence is not needed Section 7.3: - replace IMPORTS objects with IMPORTS definitions Section 8: - The comment behind LAST-UPDATED is wrong (this happens once there is redundant information) - The DESCRIPTION clause of the MODULE-IDENTITY macro says that there is supplementary information at IANA. I am not sure what this means. Perhaps this last paragraph needs to be changed to what other recent MIB modules include, namely a short version of the copyright statement. See for example RFC 7331. - This may be wrong: usmHMAC384SHA12AuthProtocol (a 5 missing) - The MIB modules compiles using smilint after fixing the RFC Ed. comments below the definition of usmHMAC256SHA384AuthProtocol and usmHMAC384SHA12AuthProtocol. Section 9.1: - I think this sentence should be changed to this: The security considerations of [RFC3414] also apply to the HMAC-SHA-2 authentication protocols defined in this document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt
On Thu, Jan 29, 2015 at 09:03:17AM +0100, Johannes Merkle wrote: s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think that s9.4 should reflect that (lest it confuses, or am I confused having missed an OBJECT somewhere?) Here I definitely need help, as I have no knowledge about MIBs. Actually, I copied that section from RFC 3411. Please give advise what to write here or if this section is needed at all. The 'official' security considerations template for MIB modules can be found here: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security It does not really apply here since this MIB module only defines a couple of constants. Perhaps write something along these lines: The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values for use in other MIB modules. It does not define any objects that can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by itself, have any effect on the security of the Internet. The values defined in this module are expected to be used with the usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The considerations in Section 11.5 of [RFC3414] should be taken into account. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib
On Wed, Jan 28, 2015 at 06:40:48PM -0500, Warren Kumari wrote: The WGLC has concluded with no feedback or comments, and so we have to conclude that the WG is no longer interested in this work. Apologies to the authors, Too bad, this document is actually useful and as far as I can tell technically sound (but then I am co-author and hence this voice does not count). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf
On Fri, Jan 09, 2015 at 07:51:16AM +1300, Brian E Carpenter wrote: Juergen, On 08/01/2015 20:26, Juergen Schoenwaelder wrote: On Wed, Jan 07, 2015 at 11:13:10PM +, Chris Grundemann wrote: On 1/7/15, 3:52 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: ... My recommendation would be to change the title to be more specific that this document is a survey report and then to submit this document as an individual submission to the RFC editor for publication... ... ... My preference still is to publish the survey via the individual stream... Please can you clarify whether your proposal is that the draft should be handled as an individual non-WG IETF Stream document sponsored by an AD, or as an Independent Stream submission to the RFC Editor. Comparing your two statements above, I don't know which you mean. I have not thought much about it but I perhaps an Independent Stream submission is most appropriate. It actually remains somewhat unclear to me _who_ conducted the survey (that is which organization was doing the work) and what the precise involvement of the Internet Society was. (Perhaps the Internet Society did this itself, but I just can't tell from reading the document.) There is also not much information (or I did not find it) about the methodology, i.e., how operators were selected / approached and the questionaire itself. But that does not matter for the question how to publish the result. If my understanding is correct that the IETF was not directly involved in this survey, I assume an Independent Stream submission may be a reasonable approach. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf
On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: Dear OpsAWG, This starts a Call for Adoption for draft-opsawg-operators-ietf. The draft is available here: https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ The I-D reports results from a survey. It is not a technical specification that a working group can work on. My recommendation would be to change the title to be more specific that this document is a survey report and then to submit this document as an individual submission to the RFC editor for publication. I do not see that a WG process can add value to the survey report. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Comments from niw.com.au operator on draft on
Hi,
for me, it is most important to finish up. This project is ongoing for
quite some time meanwhile and I think it is time to deliver. MIB
moduels can be extended after publication as Proposed Standard. I am
OK to accept these modifications if we at the same time close the door
for new features and instead wrap up this MIB module.
/js
On Mon, Sep 29, 2014 at 04:27:13PM +0900, Keiichi SHIMA wrote:
Hello Ian,
Thank you for contributing the text. I personally think the text is fine.
Let's wait for a while if we receive any comments about the text from other
authors and WG people.
I believe this modification doesn't affect the current consensus we have
about the draft. If the text is accepted by the WG, then we'll integrate it
to the draft and would like to move forward.
Regards,
---
Keiichi SHIMA (島 慶一)
WIDE project sh...@wide.ad.jp
Research Laboratory, IIJ Innovation Institute, Inc keii...@iijlab.net
On 2014/09/29, at 15:33, Ian West i...@niw.com.au wrote:
Attached is a diff against the text form of the draft, I believe I have
addressed the changes that
might be required.
Also for convenience the actual text of the proposed additional counters is
as follows.
vmStorageReadOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The total number of bytes read from this device.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor, and
administrative state (vmAdminState) changes of the
virtual machine.
::= { vmStorageEntry 15 }
vmStorageWriteOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The total number of bytes written to this device.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor, and
administrative state (vmAdminState) changes of the
virtual machine.
::= { vmStorageEntry 16 }
vmStorageReadLatency OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The total number of microseconds read requests have been
queued for this device.
This would typically be implemented by storing the high
precision
system time stamp of when the request is received from the
Virtual
Machine with the request, the difference between this initial
time
stamp and the time at which the requested operation has
completed
should be converted to microseconds and accumulated.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor, and
administrative state (vmAdminState) changes of the
virtual machine.
::= { vmStorageEntry 17 }
vmStorageWriteLatency OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The total number of microseconds write requests have been
queued for this device.
This would typically be implemented by storing the high
precision
system time stamp of when the request is received from the
Virtual
Machine with the request, the difference between this initial
time
stamp and the time at which the requested operation has
completed
should be converted to microseconds and accumulated.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor, and
administrative state (vmAdminState) changes of the
virtual machine.
::= { vmStorageEntry 18 }
Thankyou again for your consideration and feedback.
Regards,
Ian West.
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Monday, 22 September 2014 15:25
To: Keiichi SHIMA
Cc: Ian West; opsawg@ietf.org; ASAI Hirochika; SEKIYA Yuji; Tina Tsou;
Cathy Zhou; ESAKI Hiroshi; Michael MacFaden
Subject: Re: [OPSAWG] Comments from niw.com.au operator on draft on
Hi,
it would help if people would propose concrete text of what the
description of the counters would be. What is most important is that
we define counters that are implementable in a meaningful way on a
large set of different hypervisors.
/js
On Sun, Sep 21, 2014 at 09:36:55PM +0900, Keiichi SHIMA wrote:
Hello Ian,
Your description of the accumulated milliseconds (or potentially
microseconds to allow for things getting a lot faster) is exactly
what
Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp
On Fri, Aug 29, 2014 at 08:01:32AM -0400, Sam Hartman wrote: Juergen == Juergen Schoenwaelder j.schoenwael...@jacobs-university.de writes: Juergen At least, we should not confuse 'Abstract Service Juergen Interfaces', 'Subsystems', 'Models' and 'extension points' Juergen (which is a new concept since so far Models do not have Juergen such plugin extension points). Hmm, I actually do think USM has several such extension points. There does seem to be an extension point for an authentication algorithm in the model already. It's been my experience that adding security algorithms without such extension points does tend to cause problems both in interoperability because you tend to use much less pprecision when you don't need to define a clear extension point and in security because that lack of precision tends to lead to security analysis problems. I've seen this both in the routing area and with core security protocols. I don't have enough SNMP experience to figure out whether the results will be different here. Let me try to clarify my statement. I was trying to say is that we should not use references to RFC 3011 architectural modularity in this discussion since the RFC 3011 modularity concerns subsystems not what happens in modules implementing subsystems. In particular, ISMS was struggling with the fact that the subsystems did not forsee security provided by the transport. What we are discussing here is different from that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp
On Wed, Aug 27, 2014 at 01:45:43PM +0200, Johannes Merkle wrote: Sam Hartman wrote on 26.08.2014 22:26: I've reviewed both draft-hartman-snmp-sha2 and draft-hmac-sha-2-usm-snmp. I suggest that others on the list speak up and declare their preference. I can't declare a clear preference since I have not time at the moment to study whether there are any real technical differences. One thing I note, however, is that draft-hartman-snmp-sha2 lacks a MIB module and thus is incomplete. In contrast, draft-hmac-sha-2-usm-snmp includes a MIB module but it surely requires some editing work to make it look nice. Note that a MIB module is needed to define the necessary object identities for the new authentication protocols. Since both documents claim to be identical to the authentication protocols proposed in [RFC3414] except the authentication algorithms used in generating digests (quoting almost literally draft-hartman-snmp-sha2), I think short and incremental text is a feature and not a bug. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Process wonkery: Reminder about IPR relating to draft-ietf-opsawg-coman-probstate-reqs-02
On Tue, Jul 08, 2014 at 04:34:19PM -0400, Warren Kumari wrote: Are you personally aware of any IPR that applies to draft-ietf-opsawg-coman-probstate-reqs-02 or draft-ietf-opsawg-coman-use-cases? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. I am not sure whether this is a reasonable question to ask for use cases and requirements documents but in order to not complicate the process, let me declare that I am personally not aware of IPR that needs to be disclosed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-taylor-opsawg-mibs-to-ieee80231-00
s/MIBs/MIB modules/g And I would not have mind if the names of the IETF MIB modules affected would have been listed in the abstract. /js On Sun, Jul 06, 2014 at 01:16:05PM -0400, Tom Taylor wrote: I submitted this draft to put a stake in the ground. Comments welcome. I'll be bugging people to find out whether the RFC 4663 plan worked or has had to be modified in practice. Tom Taylor Title: MIBs Passed From the IETF To IEEE 802.3 and Currently Documented In IEEE 802.3.1-2013 Abstract: This document records the transfer of ownership of a number of MIBs relating to ethernet, from the IETF to IEEE 802.3. Like RFC 4663, it describes the procedures associated with the transfer. Unlike RFC 4663, this documentation is retrospective in nature, since the transfer happened several years ago. Deviations from the planned procedures described in RFC 4663 are noted for historical interest [in a later version of this draft - PTT]. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Read-write access in VMM-MIB
Asai, the IESG statement is here: http://www.ietf.org/iesg/statement/writable-mib-module.html My reading is that it specifically talks about configuration. While the discussion started with lets ban all write access, it may be important to note that the final statement does not say this. Hence, I am not sure we have to remove the MAX-ACCESS read-write. /js On Mon, May 26, 2014 at 04:24:38PM +0900, Hirochika Asai wrote: Dear all, We'd like to discuss the read-write access in the proposed MIB about virtual machine monitoring: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib . It has 10 read-write objects. All of them do not affect persistent configuration of hypervisor or virtual machines. However, according to a comment during the previous IETF meeting, the IESG statement also suggests not to include read-write objects even if they do not persist after the restart of the agent or system. In this sense, I think the following 8 objects will be read-only. 1. vmAdminState 2. vmCurCpuNumber 3. vmMinCpuNumber 4. vmMaxCpuNumber 5. vmCurMem 6. vmMinMem 7. vmMaxMem 8. vmCpuAffinity The following two objects require discussion because these objects are not related to hypervisor or virtual machines, but notifications of SNMP. The reason why I think they can be kept read-write is they are control objects of an SNMP agent and it does not affect the configuration of monitoring targets. However, from the viewpoint of security, I can agree that they should also be read-only and operators configure them not through SNMP (or something) but through another configuration scheme such as editing a configuration file. 9. vmPerVMNotificationsEnabled 10. vmBulkNotificationsEnabled I hope you give us your comments on the access of 10 objects. Thank you. Hirochika -- Hirochika Asai pa...@hongo.wide.ad.jp, The University of Tokyo ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?)
Tom, I believe the problem here is that syslog configurations tend to be rather implementation specific and finding a common core will be a non-trivial exercise. Sure, some of the complexity is on relays and collectors that filter / store / fowards syslog messages based on a number of rules, so probably there is a more well scoped problem for implementations that essentially are only syslog originators. There was some MIB work [1] in the syslog working group but as far as I can tell this work did not get much traction - only some common type definitions have been published as RFC 5427. /js [1] http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 On Mon, Apr 07, 2014 at 08:58:00AM -0400, Tom Taylor wrote: My proposal for a Yang module for SYSLOG control (at the end of this message) drew no replies. Would people at least be interested in an SNMP MIB that allowed monitoring of the controls? What I have in mind is two tables, a basic SYSLOG control table and a rate-limited event report table. The contents of the tables would be as follows. The field names are taken from RFC 5424. Basic SYSLOG Control Table: -- Key: combination of APP-NAME (general class of logs) and MSGID (specific event type). Assigned PRI value Index into rate-limited table, or nil if not rate-limited Suppressed (TRUE/FALSE) If an event type is suppressed, the associated events are totally ignored by the log system, so the assigned PRI value is not meaningful and rate-limit value should be nil. Rate Limited Log Control Table: -- Key: table index APP-NAME MSGID Reporting interval time units: seconds, hours, days, busy period. Reporting interval value: integer Maximum reports per reporting interval: integer Count of observed events Count of reported events Comments? Tom Taylor Message previously sent (28 March) == While working on draft-ietf-behave-syslog-nat-logging, I noted a number of management requirements for SYSLOG that are really independent of the particular application being logged. These include, for example, a list of events for which the operator wants logging suppressed, or specifications for rate-limiting specific event reports. For more details see Section 6, particularly sub-section 6.1.3 of the draft cited above. Would there be any interest in implementing or deploying a YANG module to provide the necessary controls if I created one? Tom Taylor ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] IoT Network Management
On Tue, Apr 01, 2014 at 02:31:33PM +0200, Hannes Tschofenig wrote: What matters most is reuse of data models. How you ship the data depends on many criteria. All I can say (since we did implement SNMP) is that SNMP works reasonably well on constrained devices. Unless you do all your tasks on an embedded device with SNMP (or a similar protocol) it seems to be the wrong choice to me since you are adding one additional protocol to implement with functionality that overlaps the other protocol. You might have some experience that I have not yet understood though (which caused me to start a discussion about it). Yes, on our constrained devices, we actually do everything via SNMP (since reading some energy sensors is pretty straight-forward to do with SNMP). And yes, if you life in a CoAP world, you likely want to do as much as possible with CoAP. (But then I must admit that we also did implement mDNS since since it is just so cool to see your sensors popping up in your mDNS enables applications. Sometimes it is the ease of reuse of existing stuff that compensates some extra implementation costs.) But yes, if you live in a CoAP world, you may prefer to ship data via CoAP (once you have worked out the details). What would be a failure in my view is to redo the data models. That's an interesting perspective. What data models from the network management community do you see most valuable? If you want to expose basic counters related to your network interfaces or your IP stack or you want to expose your IP configuration, then I think we should try to reuse what we have and not reinvent the wheel. If RESTCONF can be mapped well to CoAP and constrained devices, this may be an interesting option. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Adoption of the draft-ersue-opsawg-coman-* drafts.
On Fri, Jan 10, 2014 at 11:48:15AM -0500, Warren Kumari wrote: Hi all, We feel that we now have sufficient demonstrated interest / reviewers to adopt the draft-ersue-opsawg-coman-* drafts as WG items. Dear authors, please resubmit as draft-ietf. In addition: Are you personally aware of any IPR that applies to these drafts? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. I am personally not aware of any IPR that applies to these drafts. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*
On Mon, Jan 06, 2014 at 11:04:20AM +, Romascanu, Dan (Dan) wrote: [[DR]] hmmm ... the titles of both documents in review start by 'Management of Networks with Constrained Devices'. Is it rather 'Management of Constrained Networks and Networks with Constrained Devices'? Including management of constrained networks expands the scope considerably. In the past, we preferred to keep the scope narrow, hence the current title. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt
On Thu, Oct 17, 2013 at 05:55:13PM +0900, Keiichi SHIMA wrote: Hello, On 2013/10/15, at 23:42, Joe Marcus Clarke jcla...@cisco.com wrote: In terms of the new notifications, why enumerate all states as notifications? My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object). It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future. Ah, I misunderstood your comment. I did the change actually. Consolidating all the notification messages (maybe we will have two eventually, one is for a per VM notification, and the other is for a bulk notification) may be reasonable. # we can even unify a per vm notification and a bulk notification, but maybe it is not a good idea? If there is no strong opinion for not to unify the notification messages, then we will do the change and resubmit an updated version before the cut-off date (next Monday). I had this design (generic state change notifications) in my original MIB module but then I got convinced by Michael that many real-world applications prefer to have the notification type be specific so that they can react to the different state changes by simply looking at the notification type (without having to look into the notification payload). This is why we got to the current design. We should be careful here and take care to produce something that existing notification receivers find 'easy' to process. The number of states we have should be small and ideally not change over time, so the implementation costs on the agent side likely are not big. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: question about vmAdminState values
On Fri, Aug 30, 2013 at 06:08:10PM +0900, SHIMA Keiichi wrote: If I'm not missing, there is no other explanation about how the vmOperState should behave. Maybe we need more concrete description in the vmOperState section. Currently, it just says as below. The current operational state of the virtual machine. I think this is pretty clear - it is the _current_ _operational_ state and indeed a virtual machine may cycle between states or it may go through a sequence of state changes while carrying out a complex administrative action like migrate from hypervisor A to B. The MIB module is not modeling such administrative actions - its aim is only to report what is actually happening for monitoring or troubleshooting purposes. In other words, if you instruct your hypervisor controller to migrate a virtual machine from hypervisor A to B, then the MIB module allows you to monitor how this migration process is carried out. I see this very similar to process states and process state changes at the operating system level. If you, for example, tell an application to terminate, then the underlying processes still go through a sequence of state changes until they finally (hopefully) disappear. Also, if we keep the blocked state and the state machine figure, then it would be better to provide a complete state transition table. The current figure-style state machine lacks transition flows between the blocked state and other states. I don't want to draw that part in the figure, since it will mess up the figure :) How about adding a separate table in a appendix section? Perhaps we can add an arrow from running to blocked and another from blocked to running. But I would not try to cover all possible transitions since you can transition into the crashed state from many states. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: question about vmAdminState values
On Thu, Aug 29, 2013 at 07:27:40PM +0900, SHIMA Keiichi wrote: [...] Do we have any usage scenario of the blocked state? I thing this is backwards. I like my SNMP agent to access the current state and report it. It does not matter whether I believe the state is short lived or not. I like to see the actual state - not a translation of it. The worst experience when I debug problems is when software tries to hide reality. And, btw, being blocked is really not uncommon in a Xen setup. $ sudo xm list NameID Mem VCPUs State Time(s) Domain-0 0 4160 8 r- 267537.1 foo 3 512 1 -b 39148.0 bar 17 2048 1 -b 71467.1 baz 20 2048 1 -b 80750.0 bing 6 1024 1 -b 66408.8 bong 8 256 1 -b 57365.8 bang21 1024 1 -b 36534.1 yum 10 256 1 -b 41611.5 yam 15 1024 1 -b 49363.2 yim 16 2048 1 -b 44081.6 (Taken from a live machine with names obfuscated.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On Wed, Aug 21, 2013 at 02:27:08PM -0400, Joe Marcus Clarke wrote: That's fair. I was not aware of the ability to adjust VM CPU and memory on the fly without touching the config. That said, I struggle to understand the use case of doing this via SNMP versus a more reliable API. In the MIB world, we have ways to express things in such a way that people who want to implement a writable object can do so without causing costs to those who prefer to not do so. This is why we have MAX-ACCESS (what makes 'protocol sense' - means in principle this is a writable object) and MIN-ACCESS (the minimal level of access - means the minimum access one has to implement in order to comply to a conformance definition). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On Mon, Aug 19, 2013 at 04:38:28PM -0400, Joe Marcus Clarke wrote: We seem to agree on the general scope. Now we have to determine which objects reasonably have a MAX-ACCESS or read-write. For me, it seems that vmAutoStart likely should indeed be read-only. However, as far as I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem at runtime without touching persistent config state. If the WG's intent is to leave them as RW (and I can see that certain HV's allow this sans persistence), then there should be stronger guidance (I think) that indicates that these are operational-only objects and the new values should not be persisted. But that may be too messy. There is already text like this: Changes to this object may not persist across restarts of the hypervisor. What is your proposal to make this clearer / stronger? Is there a strong push from operators to toggle these values via SNMP? Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it 'defines whether it makes protocol sense to read, write and/or create an instance of the object, or to include its value in a notification'. The compliance statement vmReadOnlyCompliances says that write access is not required to be implemented. I believe this is how we commonly do things in a MIB module - we allow read-write implementations but we do not require read-write implementations. Hence, I prefer to make no changes (except perhaps vmAutoStart but I need to check whether there are hypervisors that actually allow to change autostart behaviour of the running instance without touching persistent config - this might actually be possible). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04)
On Mon, Aug 19, 2013 at 11:02:15AM -0700, Michael MacFaden wrote: Marking this item as Proposal: Joe-2 JMC: I think there should be an object in this table such as vmMgmtAddr, which lists the management IP address of the VM. This would be akin to what one would see in vCenter for a VMware-controlled VM. As a manager, this would be very useful in being able to discover other potential SNMP agents in the network. Do you want this managed object to report only if there is a configured mgmt agent running in the guest OS(GOS)? There can be more than one mgmt address per address family. In our systems, the hypervisor has no clue which IP addresses are used by the guest OSes (and surely the hypervisor does not know which IP addresses would be management addresses). We use a virtual bridge to connect the VMs. Can we not use the same discovery techniques that can be used today to discover devices (e.g. connected to a physical bridge) to discover virtual machines? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On Mon, Aug 19, 2013 at 11:26:06AM -0700, Michael MacFaden wrote: Marking this proposal as Joe-3 JMC: The purpose of this MIB is not to provide configuration of the hypervisor. Quoting section 3.2: The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. Right. To that end, I find objects like vmAutoStart, vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, vmAutoStart mentions the word configuration in its description. And the other objects, at least from a VMware standpoint are actually specified in the VM's configuration. One would have to, for example, shutdown the VM to increase the number of vCPUs allocated to the VM. Such behavior really depends on the hypervisor. Adding a CPU while VM is running has been a feature of VMware for some time now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html Therefore, I feel all of these objects represent persistent changes to the hypervisor in support of the respective VM. I think these objects should go away and only the read-only objects showing current vCPU allocation, affinity, and memory stats should remain. As for auto-start, that can be read-only. My position as well. Once you go read-create/write the complexity grows and description fall short of any real standard behavior in response to a mutational set is almost always lost. The alternative is to say that some persistent changes will be allowed (such as auto-start), but general VM resource configuration will be out of scope. Mark this as Joe-3A. As I said above, I'm not interested in standardizing configuration of Virtual Machines via SNMP. Neither are the operators I know. We seem to agree on the general scope. Now we have to determine which objects reasonably have a MAX-ACCESS or read-write. For me, it seems that vmAutoStart likely should indeed be read-only. However, as far as I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem at runtime without touching persistent config state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04)
On Mon, Aug 19, 2013 at 02:38:40PM -0400, Joe Marcus Clarke wrote: Sure. This just presents another, maybe simpler way to find VMs in particular in the network. I fully understand that this address may be 0, but I know at least for the VMs I maintain, it would be a useful value. I do not question the value (although an IP address still requires guess-work to talk to a management interface successfully). I am saying that it is not at all easy to implement such an object since the hypervisor may simply have no clue which IP addresses are used by the guest OSes (and which subset would be 'management' addresses). It might work in your case - but we need to maintain a somewhat broader view I think. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [OPS-AREA] suggested updates to draft-asai-vmm-mib-03.txt
On Tue, May 21, 2013 at 03:24:00PM -0700, Michael MacFaden wrote: And of course, with your notification design, it makes a lot of sense to assign small VirtualMachineIndex values (right now, I can choose 2147483647 as vmIndex but that would be a really bad choice for your new notifications). Yes, and starting a simple index from 1 remains a strong SNMP convention since RFC 1213 through RFC 2863 for ifIndex. We better be explicit if we adopt your notifications. I have seen boxes with rather large ifIndex values that seemed to resemble memory locations of device drivers. As you can see from my patch, by including the managed object vmBulkNotificationsEnabled, I believe both models merit inclusion in the standard. Yes, but whether an application is fine with bulk notifications or prefers separate notifications is actually a function of the application behind the notification receiver. In other words, I can see situations where some notification receivers prefer bulk notifications while others prefer the other type of notifications. In principle, SNMPv3 has a mechanism to deal with this, namely the notification filtering mechanism described in section 6 of RFC 3413. So perhaps the way to go is to have two 'enable' objects that enable the generation of the two classes of notifications (so you can enable both, only one of them, or none) and to add explicit text how RFC 3413 notification filtering can be used to control which notification receiver receives certain notifications. Makes sense? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [OPS-AREA] suggested updates to draft-asai-vmm-mib-03.txt
On Tue, May 07, 2013 at 11:27:05AM -0700, Michael MacFaden wrote: Juergen wrote: can you please send this message to the OPSAWG mailing list? We need to move discussions over to the list. Attached please find my suggested patch to the draft-asai-vmm-mib-03.txt In short: 1. Introduce a new TC called VirtualMachineList. It is a clone of Q-BRIDGE-MIB PortList 2. Introduce a new managed object, vmBulkNotificationsEnabled, to report which type of events to receive, either bulk or existing per vm notifications. 3. Adds a parallel set of notifications to match: vmRuning, vmShutdown, vmPaused, vmSuspended, vmCrashed, vmDeleted that only send a new accessible-for-notify variable vmAffectedVMs using SYNTAX VirtualMachineList. Thanks Michael. I am wondering whether we should really have two sets of notifications. I know that we discussed this before but lets me ask again: How large is the number of VMs per hypervisor going to be we have to plan for? I am asking so that I can get an idea what the length of vmAffectedVMs might be - I guess we are fine but I just thought I ask. And of course, with your notification design, it makes a lot of sense to assign small VirtualMachineIndex values (right now, I can choose 2147483647 as vmIndex but that would be a really bad choice for your new notifications). The old notifications carry more information. Hence, if we would move to the new notifications, a management application may send subsequent read requests to obtain that information. But perhaps this is OK since this is under the control of the management application (while a notification blast is not). Lastly, I've added some comments (grep mrm) about what clients should expect with vmName, vmUUID, vmIndex based on my prior deployment experience with the similarly structured VMWARE-VMINFO-MIB. These make sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-asai-vmm-mib: Issues on notifications
On Thu, Apr 11, 2013 at 09:56:08PM -0700, Randy Presuhn wrote: Hi - From: Hirochika Asai pa...@hongo.wide.ad.jp To: opsawg@ietf.org Sent: Wednesday, April 10, 2013 5:36 PM Subject: [OPSAWG] draft-asai-vmm-mib: Issues on notifications ... o Issue 1-1) Scalability issue on notifications: The number of virtual machines managed by a bunch of hypervisors in a datacenter possibly becomes several thousands or more. If these virtual machines frequently change their administrative state, many notifications could be trapped. Since an SNMP manager has to handle SNMP traps of these notifications, there exists a scalability issue on handling them. Should we add some `vmXXXNotificationEnable' objects to disable traps for each notification? Or any other ideas? ... RFC 3014 might be helpful here, and possibly RFC 3877. I think Michael wanted to post notification definitions that help reduce the number of notifications emitted if for example all virtual machines of a hypervisor change state at about the same time (e.g., because the physical server is restarted). This may be a good thing since it reduces the number of notifications at the source and as such works independently of RFCs 3014 or 3877. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-asai-vmm-mib: Issues on notifications
On Fri, Apr 12, 2013 at 11:09:18AM -0700, Randy Presuhn wrote: Hi - From: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de To: Randy Presuhn randy_pres...@mindspring.com Cc: opsawg@ietf.org Sent: Thursday, April 11, 2013 11:36 PM Subject: Re: [OPSAWG] draft-asai-vmm-mib: Issues on notifications ... o Issue 1-1) Scalability issue on notifications: The number of ... I think Michael wanted to post notification definitions that help reduce the number of notifications emitted if for example all virtual machines of a hypervisor change state at about the same time (e.g., because the physical server is restarted). This may be a good thing since it reduces the number of notifications at the source and as such works independently of RFCs 3014 or 3877. For that specific use case, a notifcation identifying the hypervisor to which those VMs belong, rather than the individual virtual machines, would seem a better way to go. One might even argue that the coldStart notification type could be sufficient to do the job. Yes, for this use case - I assume Michael has more insights whether there are other use cases where subsets of all machines of a hypervisor change state together. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB
On Wed, Sep 19, 2012 at 12:04:23PM +0200, Romascanu, Dan (Dan) wrote:
All these seem useful extensions.
I am willing to be a reviewer as well if this work is chartered.
Question to Juergen - what would be a (rough) definition for the
hrSWRunPerfVirtualMem object?
Something like this:
hrSWRunPerfVirtualMem OBJECT-TYPE
SYNTAX KBytes
UNITS KBytes
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The total amount of virtual memory allocated to
this process.
::= { hrSWRunPerfEntry 3 }
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 http://www.jacobs-university.de/
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
