Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt

From: "Beard, Cory" <[email-masked]>
Date: Sat, 6 Jul 2002 12:29:54 -0500

> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Friday, July 05, 2002 12:33 PM
> Fine, but mechanisms (e.g. QoS) should be discussed in separate
> documents from the high-level requirements document.  Right now
> we don't have a high-level requirements document -- instead we
> have a document that claims to be high-level requirements but
> instead mixes and confuses mechanisms with requirements.  This
> is a serious bug, one which that document's authors seem disinclined
> to respond to when I raised it in the past.

Ran,

As one of the authors, I am still unclear about your problems with the
requirements document.  Let me step through the draft.

Section 1 is the introduction.  I assume you have no problems with that,
since all it does is put the problem in context.

Section 2 lists requirements at the highest level - availability,
dependability, authorized access, security protection, and privacy.  I
assume you have no problems with those.  These are exactly what you have
been saying you want to see.

Section 3 seems to be where you have a problem.  It does discuss QoS
mechanisms, but it starts with, "it is assumed that networks will
experience temporary scarcity of resources, especially because of
damaged infrastructure and high demand immediately following a disaster.
If a service provider employs an over provisioning approach to provide
emergency services so that resources are never scarce, some of the
following requirements might not be necessary."  I do not see why this
section would be a problem given that it starts with this caveat that it
may only apply to some implementations.

Section 4 simply gives providers the *opportunity if they wish* to
differentiate their services based on applications or traffic types.  I
do not see why there should be a problem here.

Section 5 lists the policy decisions providers need to make.  It does
not tell them how to make the decisions, it only requires that they
openly describe the policies they are using.  No problem here?

Section 6 gives some application (not implementation) examples.  Section
7 closes.  No problem here?

I TOTALLY agree with your concerns and perspectives on the issues, but
do not understand your objections with the document.  

It would be very helpful if you could give specific comments about
specific sections, instead of generic criticisms.  Then we can address
your comments and move forward to make appropriate adjustments.

Do you think we should we remove Section 3?  Should the whole document
only be Section 2?  Is your only problem just some of the way the
introduction is written?

Cory Beard

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 6 Jul 2002 13:49:53 -0400

> requirements document.  Let me step through the draft.

Cory,

There is a missing opening section, which I would call SCOPE.
The main text in the SCOPE section ought to read something like
this:

	Nothing in this document is applicable to an IP network that
	does not claim to offer emergency network services.  This
	document describes high-level requirements for IP networks
	that do claim to offer emergency network services.  Examples
	of emergency network services are provided elsewhere [other 
document cite].
	Possible mechanisms for deploying emergency IP network services
	are discussed elsewhere [optional: other document citations].

> since all it does is put the problem in context.

I think it is a bit long and confusing.  I also think it confuses 
telephony
issues (e.g. current US GETS) with network issues.  I would like to see
this improved, but it is not my main concern with your document.

> been saying you want to see.

This section is closer than most, but delves into mechanisms here
and there.

> may only apply to some implementations.

Section 3 should be moved into one or more separate documents, because it
does not describe *requirements* but instead describes *mechanisms*.
A requirements document ought be just that -- a *requirements* document.
This section is too detailed about mechanisms.  Section 2 was very much
closer to the mark for requirements.

> do not see why there should be a problem here.

This also should be in a separate document.  It is essentially providing
some sidebar information from the authors, rather than *requirements*
for an IP network operator.

> openly describe the policies they are using.  No problem here?

This is not as bad as 3, but it is not clear to me that a provider 
inherently
*needs* to make each of these decisions, particularly if the IEprep
service is considered from a global perspective rather than a US-centric
perspective.  This section seems quite US-centric.

> 7 closes.  No problem here?

Please move Section 6 into a separate document with examples of IEprep 
applications.
I'd suggest combining it with a bunch of the material currently in 
Section 1.

> do not understand your objections with the document.

Hopefully this note will help.

> your comments and move forward to make appropriate adjustments.

I did offer a fair bit of detail once before, but maybe that note got 
lost.

> only be Section 2?  Is your only problem just some of the way the

I've outlined specific changes above.  I'll take an editorial pass at
the whole thing and see if I can't mail a strawman revised version out
later this weekend.  Please keep in mind that my concern here is mostly
to have the requirements document be clear, thin, and focused.  If one
feels that it is important to have detailed discussion of other material,
that other can better be placed into separate documents 
(cross-referencing as
appropriate).

Ran
[email-masked]

---

From: "Alistair Munro" <[email-masked]>
Date: Mon, 8 Jul 2002 09:30:36 +0100

Hi Ran,

If you are preparing some detailed changes to this draft than I will
hold fire on some other minor wording changes that I wanted to send in.

In general and as I have said in the past, I find the draft useful and
informative. For an ISP or implementer of emergency services it explains
the main issues and would assist in (respectively) responding to, or
preparing, an operational requirement. In particular I don't want this
to become a set of MUST requirements.

I think it is reasonable to refer to standardised solutions and
mechanisms, as it may well be a functional requirement to have these
mechanisms to implement emergency services. 

On specific sections:

1. Move 1.1 to 6 (subsection of 6.4?), retitled as GETS - it is an
example and is not about "Current PSTN Capabilities".

2. OK.

3. Contrary to your suggestions, I would keep this and rename it
"Service Differentiation for Control and Delivery".
3.1, 3.2: "Should" is too strong. Replace with "MAY"

4. Subsume into 3, i.e. 4.1 -> 3.4, 4.2 -> 3.5. Delete introductory
paragraph "In addition..."

5. OK by me. We have been into all this US-centric stuff before. I don't
find it US-centric at all.

6. OK.

7. OK,

8. Delete - it doesn't add any value to 2.4.

As an implementer, I need to have guidance on security, service
differentiation, priority/pre-emption at application level, and we are
seeing outputs emerging on these. This draft is a good introduction and
complement to these specific protocol practices. It should be kept
intact.

Regards,

Alistair

--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.u4eagroup.com

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 8 Jul 2002 09:01:16 -0400

> mechanisms to implement emergency services.

I think it is fine to have some example solutions, in separate documents.
I object pretty strongly to the standard mandating a particular mechanism
because network designs and circumstances vary so widely.

> 3.1, 3.2: "Should" is too strong. Replace with "MAY"

I don't propose dropping it, but rather moving it into a separate
document.

> find it US-centric at all.

Some other Europeans do find it US-centric.

> complement to these specific protocol practices. It should be kept

The deployment guidance is fine and useful, but needs to be in separate
documents -- so that requirements (i.e. MUST items) are separated
from options (i.e. other items).

Thanks for your note.  It is helpful to have specific understandings
of the differences in perspective.

Ran
[email-masked]

---

From: "Alistair Munro" <[email-masked]>
Date: Mon, 8 Jul 2002 14:47:19 +0100

Hi Ran,

> I think it is fine to have some example solutions, in 
> separate documents. I object pretty strongly to the standard 
> mandating a particular mechanism because network designs and 
> circumstances vary so widely.
> 

Section 3 seems, (to me), to say packets should (I prefer MAY) be given
differential treatment but it does not mandate anything specific - my
reading is that the only requirement is to give emergency traffic a
better-than-best-effort service and the mechanism is not mandated.
However the DSCP marking *is* a standard and if used, SHOULD be used
according to best practice. This is one of the sections that I have some
alternate words for, pending your own input.

> > "Service Differentiation for Control and Delivery". 3.1, 
> 3.2: "Should" 
> > is too strong. Replace with "MAY"
> 
> I don't propose dropping it, but rather moving it into a 
> separate document.
> 

Sorry, I did not express myself too well. I meant: keep it in this
document. Keeping everything together makes for easier maintenance.

> > 5. OK by me. We have been into all this US-centric stuff before. I 
> > don't find it US-centric at all.
> 

I would be interested to review any proposed text changes that
generalise it.

> 
> The deployment guidance is fine and useful, but needs to be 
> in separate documents -- so that requirements (i.e. MUST 
> items) are separated from options (i.e. other items).
> 

I'm happy to see MAYs and SHOULDs in this document, which is, after all,
only going to be an Informational RFC.

Regards,

Alistair