Skip to main content

Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain
RFC 4375

Revision differences

Document history

Date Rev. By Action
2015-10-14
06 (System) Notify list changed from sob@harvard.edu, kimberly.s.king@saic.com to kimberly.s.king@saic.com
2006-02-06
06 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-02-06
06 Amy Vezza [Note]: 'RFC 4375' added by Amy Vezza
2006-01-25
06 (System) RFC published
2005-11-17
06 (System) New version available: draft-ietf-ieprep-domain-req-06.txt
2005-11-07
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-10-31
06 Amy Vezza IESG state changed to Approved-announcement sent
2005-10-31
06 Amy Vezza IESG has approved the document
2005-10-31
06 Amy Vezza Closed "Approve" ballot
2005-10-28
06 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2005-10-28
06 (System) Removed from agenda for telechat - 2005-10-27
2005-10-27
06 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-10-27
06 Alex Zinin
[Ballot comment]
A small note on the following para:

4.2 Redundancy

  The issue of making networks fault tolerant is important and yet not
  …
[Ballot comment]
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.
2005-10-27
06 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-10-27
06 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-10-27
06 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-10-26
06 Michelle Cotton IANA Comments:
No IANA Considerations section.
We understand this document to have NO IANA Actions.
2005-10-25
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-10-25
06 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2005-10-25
06 Bert Wijnen
[Ballot comment]
I see:
  3.8 MIB

  Management Information Bases (MIBs) SHOULD be defined for mechanisms
  specifically in place to support ETS.  These …
[Ballot comment]
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.
2005-10-25
06 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2005-10-24
06 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-10-24
06 Brian Carpenter
[Ballot comment]
Gen-ART comments from Scott Brim (two fixes needed)

>>    Any application layer label mechanisms used to support ETS MUST be
>>    …
[Ballot comment]
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
2005-10-24
06 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-10-20
06 Jon Peterson [Note]: 'Note the RFC-Editor note that removes the reference in the Abstract.' added by Jon Peterson
2005-10-20
06 Jon Peterson Placed on agenda for telechat - 2005-10-27 by Jon Peterson
2005-10-20
06 Jon Peterson State Changes to IESG Evaluation from Waiting for Writeup by Jon Peterson
2005-10-20
06 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2005-10-20
06 Jon Peterson Ballot has been issued by Jon Peterson
2005-10-20
06 Jon Peterson Created "Approve" ballot
2005-10-20
06 (System) Ballot writeup text was added
2005-10-20
06 (System) Last call text was added
2005-10-20
06 (System) Ballot approval text was added
2005-09-13
05 (System) New version available: draft-ietf-ieprep-domain-req-05.txt
2005-07-14
06 Jon Peterson State Changes to Waiting for Writeup from AD Evaluation by Jon Peterson
2005-07-12
06 Jon Peterson State Changes to AD Evaluation from Publication Requested by Jon Peterson
2005-04-11
06 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-02-07
04 (System) New version available: draft-ietf-ieprep-domain-req-04.txt
2004-12-02
03 (System) New version available: draft-ietf-ieprep-domain-req-03.txt
2004-09-22
02 (System) New version available: draft-ietf-ieprep-domain-req-02.txt
2004-06-14
01 (System) New version available: draft-ietf-ieprep-domain-req-01.txt
2004-01-12
00 (System) New version available: draft-ietf-ieprep-domain-req-00.txt