Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt

From: Randy Bush <[email-masked]>
Date: Tue, 25 Jun 2002 10:23:32 -0700

this looks a lot like protocol and not like requirements

	Title		: Recommended Packet Marking Policy
	Author(s)	: F. Baker
	Filename	: draft-ietf-ieprep-packet-marking-policy-00.txt
	Pages		: 17
	Date		: 24-Jun-02
	
given the charter and scott's recent posting of allison-sounding words,
please explan how this got to be an ieprep wg document.

randy

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Jun 2002 11:57:51 -0700

>please explan how this got to be an ieprep wg document.

Please go re-read the charter. The working group is supposed to come up 
with requirements, and one or more BCPs of specific recommendations - no 
new protocols, but instructions on how to use existing ones - to meet ETS 
needs.

This is absolutely within charter.

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Jun 2002 13:04:49 -0700

> Date: Tue, 25 Jun 2002 08:50:50 -0400 (EDT)
> From: Scott  Bradner <[email-masked]>
> To: [email-masked]
> Subject: Re:  [Ieprep] IPsec vs TLS for SIP message protection
> 
> AD hat on
> 
> this thread has been interesting but out of scope for this working group.
> 
> this group is supposed to be developing requirements not debating solutions
> - focusing on solutions at this point is out of scope but also limiting in
> that understanding what a suggested solution can offer tends to redefine
> the requirement to meet the solution

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Jun 2002 16:37:14 -0700

Great, Randy. Now go back and read the parts of Scott's message that you 
didn't quote. The particulars of adding protocol information elements to 
SIP, that are not now present and may be the wrong way to architect the 
solution, are beyond our charter. Making a BCP identifying what DSCP values 
to use - from existing standardized PHBs - is specifically part of our charter.

---

From: "Alistair Munro" <[email-masked]>
Date: Wed, 26 Jun 2002 08:30:28 +0100

Hi All,

I support Fred's draft, apart from a few typos, and the tone of some of
the text. It is not clear, from other comments, how it fits the charter,
but this needs only a sentence to clarify.

I have only general comments:

Section 1.1 - says why you need to differentiate services but does not
follow through the rationale for the emergency situation. Not sure about
the first bullet "It has not always..." - true, but is it relevant,
except as a comment on supply and demand? I would remove it. Last
paragraph of 1.1 "The intent..." could move to become the last paragraph
of the Introduction.

Section 1.2 - the updates/clarifications to RFC2475 should be cited. I
find the text useful to define the concepts used in section 2. It might
be worth considering

Section 1.3 - PHB is a key Diffserv term, although every hop has a
behaviour, DiffServ or not. Move into 1.2? Define AF and EF, which are
used without definition in 1.2.3.

Section 2 - the table seems clear BCP. Direction on using DSCPs not
mentioned in the table is also part of current practice and has a
certain set of rules attached to it.

Section 2.1 - RP -> RTP?, SIP -> SIP and/or H.320?

Section 2.2 (and others) - is ECN part of DiffServ, is it BCP? Needs
clarification (in 1.2.2?). Reference to [4] as "active queue management"
- typo?

Section 3 - as an implementer I don't have any issue with the policy and
practice recommendations (apart from the usual problems of implementing
policy). I don't think it's specific to IEPS, although IEPS has revealed
it. There are many other issues hinted at in this section that
illustrate the difficulties of deploying DiffServ, particularly global
vs. local configuration. The report from the Internet2 Premium Service
experiment:

http://mail.internet2.edu:8080/guest/archives/qbone-arch-dt/log200205/ms
g00000.html

has some useful reference material. 

Section 4 - just say there are no security issues? Move first paragraph,
apart from the last sentence, to the introductions. Move second
paragraph in to section 3.

I have some detailed text edits, but I'll pass these on paper at the
meeting.

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