Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain
Note: This ballot was opened for revision 06 and is now closed.
(Jon Peterson) Yes
(Brian Carpenter) No Objection
Comment (2005-10-24 for -)
Gen-ART comments from Scott Brim (two fixes needed) >> Any application layer label mechanisms used to support ETS MUST be >> capable of supporting both the set of ETS and non-ETS (presumably, >> normal) users. > > > I'm not sure about this one, perhaps because I don't understand what > it means. I can envision, for example, applications that are only > used in ETS situations, and are only capable of running with ETS > labels. Are they disallowed? No special apps? > > I can see a requirement that any application which is used during > normal times must still be usable during "medium emergencies". Is > that the goal? the intent of the requirement was to discourage designs/ specifications that totally ignore a "normal" condition -- even if the application is used exclusively by ETS type users (e.g., first responders like Fireman). The practice of taking into account the "normal" condition is found in existing specifications of MLPP, eMLPP for GSM, and Project 16 for mobile radio. admittedly, when the above requirement was written, I had in mind existing IETF applications and I wanted to squash any attempted augmentation that damaged its legacy operation for "normal" or non- ETS type users. How does the following sound? Regarding existing IETF specified applications, augmentations in the form of labeling mechanisms to support ETS MUST NOT adversely affect its legacy usage by non-ETS users. With respect to future applications, such labeling mechanisms SHOULD allow the application to support a "normal" (non-emergency) condition. > Also a nit in case there is another version ... > > >> If proxies take such action, then the security measures discussed in >> [rfc3689] MUST be considered. More discussion about security in the >> single domain context is discussed in section 5. >> > > You don't mean to say that the discussion is discussed. :-) thanks for catching that. it will be fixed :) -ken
(Bill Fenner) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
(Bert Wijnen) No Objection
Comment (2005-10-25 for -)
I see: 3.8 MIB Management Information Bases (MIBs) SHOULD be defined for mechanisms specifically in place to support ETS. These MIBs MAY include objects representing accounting, policy, authorization. I suggest to change to: 3.8 MIB Management Information Base (MIB) modules SHOULD be defined for mechanisms specifically in place to support ETS. These MIB modules MAY include objects representing accounting, policy, authorization. That is: there is one single MIB, which is composed of many MIB modules. I am not sure I understand the capitalized MAY in the 2nd sentence. I can live withit, but porbably better to just use lowercase "may". The discussion about MIB and SNMP in the Security Considerations section is porbably best changed/updated to state a subset of the text in the common MIB Security Template as found at http://ops.ietf.org/mib-security.html Specifically, I think I would like to see text aka: SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Which I think covers the considreations that are relevant for this MIB document.
(Alex Zinin) No Objection
Comment (2005-10-27 for -)
A small note on the following para: 4.2 Redundancy The issue of making networks fault tolerant is important and yet not one that can be easily articulated in terms of requirements of protocols. Redundancy in connectivity and nodes (be it routers or servers) is probably the most common approach taken by network administrators, and it can be assumed that administrative domains apply this approach in various degrees to there own resources. Actually, as far as articulation of network fault tolerance is concerned, work that's been done on MPLS and IP Fast Reroute gives us a very good idea how this can be quantified: the major two parameters are the service restoration delay (in ms), and failure coverage (in %% of ingress-egress router pairs). For the former, the commonly accepted target is 50ms, and the latter entirely depends on the level of redundancy in the network, and as such can be used as a quantative metric for it.