Subject: [PCN] Response to AD Review: draft-ietf-pcn-sm-edge-behaviour-04

From: Tom Taylor <[email-masked]>
Date: Mon, 13 Dec 2010 11:07:21 -0500

Here are my proposed responses to your first review note, based in part 
on list discussion. Do they meet your concerns?

PCN WG, is this OK for you?

======================

Hi,

I have performed an AD Review of draft-ietf-pcn-sm-edge-behaviour-04
and have some comments.

1) As I reviewed both the SM and CL edge behavior documents, I noted
with concern how similar the documents are. I wonder if you wouldn't
be better having one document, with common text in the early chapters,
and then a section for SM and a section for CL. Or even three
documents, to pave the way for addiitonal behavior documents.

The real concern is that when you have so much common text, you need
to work hard to keep them consistent. An additional concern is that
the IETF (in LC) IESG (in IESG Eval) will need to review these docs,
and check that you haven't overlooked anything; the IETF and IESG
basically perform sanity checks. This is made harder when the text is
almost the same in the two documents. If the editorial text is just
slightly different in multiple places, it becomes much harder to find
the important differences between the documents.

[snip]

if you are going to have two documents with so much common text, I
will expect the editorial text to be consistent, so the technical
differences are clear.

----------------

[PTT response] I propose that we:

  a) Add the following paragraph at the end of Section 1 (CL version shown):

"A companion document [I-D.SM-edge-behaviour] specifies the Single 
Marking (SM) PCN-boundary-node behaviour. This document and 
[I-D.SM-edge-behaviour] have a great deal of text in common. To simplify 
the task of the reader, the text in the present document that is 
specific to the CL PCN-boundary-node behaviour is preceded by the 
phrase: "[CL-specific]". A similar distinction for SM-specific text is 
made in [I-D.SM-edge-behaviour]."

b) Take a diff between CL-07 and SM-04, eliminate the purely editorial 
differences, and tag the technical differences as indicated by the above 
paragraph.

=====================

2) Why are individual flow identifiers reported for
excess-traffic-marked PCN-traffic for CL but not for SM? Wouldn't this
be useful for both?

[PTT response] Answered in a previous E-mail -- a matter of not having a 
sufficiently precise trigger with SM to know whether the flow 
identifiers should be collected or would be meaningful. I can't think of 
a text proposal, since it would logically belong in the SM draft but 
would be an explanation for text that isn't there.

=====================

3) From Acknowledgements:    The authors thank Ruediger Geib for his
useful comments.  The acknowledgements in the CL boundary node
behaviour draft really apply here, too.
dbh: the CL draft is likely to be an RFC. If you want the
acknowledgement in both places, put it in both places.

[PTT response] Will do as part of the editorial synchronization.

=====================

4) I would be careful referencing other works-in-porgress, just in
case anything slows down the other document(s). No sense holding up
the publication of this document because another document runs into a
delay.

[PTT response] Some of that is purely historic, and the documents have 
long expired. I see no harm in cross-referencing between the SM and CL 
drafts, though I should possibly use RFCyyyy notation. I-D.PCN3in1 will 
be dropped from the CL draft, per list discussion.

======================

5) please check all lower-case RFC2119 keywords. The IESG prefers that
they be uppercased to make it clear they are normative. I recommend
using "might" rather than "may" for non-normative, and re-wording
musts, shoulds, and recommends to avoid using lowercased reserved
words.

[PTT response] I think the usual situation where we run into this is 
talking about what an operator could do. Will check it out.

======================

6) section 3.2 and section 3.3.2 both present the formula for CLE, but
they present it differently. Just a style issue, but I recommend
presenting it consistently.

[PTT response] OK

=======================

7) section 3.3 "The Decision Point MUST"; I recommend saying "A
compliant Decision Point MUST"

[PTT response] OK

=======================

8) "PCN traffic" is used here, but where that term is defined is not
mentioned. Since this is used in formulae, that could be important to
understand correctly.

[PTT response] I propose to add the following definition:

PCN-traffic			
	An octet stream consisting of PCN-packets considered
         within a specific context.

=======================

9) in 3.5, do we really need both t-meas and T-meas, etc.? The chart
would be easier to read if you eliminated one of the redundant
columns.

[PTT response] OK

=======================

10) in Table 1, some word breaks are missing from the Action on Expiry
column. Put a space between conditionally and CLE, and between each
and IEA.

[PTT response] That was XML2RFC, fitting things into too little space. 
Eliminating one of the columns will fix that. I also propose to drop the 
word "conditionally" -- too much detail in a summary table.

=======================

11) The acronym IEA is not defined before being used.

[PTT response] Will add an expansion in the preamble to the table.

=======================

12) t-maxsuppress has discussion of the value to use for an unreliable
transport; what is the recommended value for a reliable transport?

[PTT response] The discussion is actually back up in section 3.2.3. The 
whole question of transport will be reframed in view of the realization 
that the choice of transport will be made in the IETF, not by the 
operator. The suggestion on the PCN list was to specify default values 
for all the timers, then say that any transport specification for PCN 
must (or is that MUST?) propose alternative values if the ones proposed 
in this document seem unreasonable for the chosen transport.

Default values are currently given in the body of the text (e.g., in 
section 3.2.1). I'm wresstling with the question of whether they should 
stay there or be replaced by forward references to section 3.5.

=======================

13) section 4 title has extra spaces.

[PTT response] OK, will fix.

=======================

---

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Dec 2010 12:00:35 -0500

Hi,

This looks good. a few comments inline.

dbh 

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Monday, December 13, 2010 11:07 AM
> To: David Harrington
> Cc: pcn
> Subject: Response to AD Review: draft-ietf-pcn-sm-edge-behaviour-04
> 

If you b), then a) is unnecessary, although it might be helpful for
people to see the distinction more easily. I would live with having
it,ot not having it, as long as b) is done.

> talking about what an operator could do. Will check it out.

Is PCN-packets defined?

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 13 Dec 2010 18:14:43 -0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Harrington
> Sent: 13 December 2010 17:01
> To: 'Tom Taylor'
> Cc: 'pcn'
> Subject: Re: [PCN] Response to AD Review: draft-ietf-pcn-sm-edge-
> behaviour-04
> 
> Hi,
> 

<SNIP>

> >          within a specific context.

Extract from RFC5559:

o  PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of
      different Diffserv behaviour aggregates (BAs) [RFC2474].  The
      PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the
      corresponding packets are PCN-packets.  The same network will
      carry traffic of other Diffserv BAs.  The PCN-BA is distinguished
      by a combination of the Diffserv codepoint (DSCP) and ECN fields.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Dec 2010 14:03:28 -0500

Hi,

There were a few places where a clear definition of PCN-packets or PCN
traffic would have made the spec less ambiguous. You might want to
include this definition text in the terminology section.

Normally, I do not encourage copying normative text from another
document, because keeping things in sync can be difficult, but here I
think it might be helpful. However, this document should be clear
where the normative definition is, so you might do something like:

o  PCN-traffic, PCN-packets, PCN-BA (from RFC 5559):
      a PCN-domain carries traffic of
      different Diffserv behaviour aggregates (BAs) [RFC2474].  The
      PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the
      corresponding packets are PCN-packets.  The same network will
      carry traffic of other Diffserv BAs.  The PCN-BA is
distinguished
      by a combination of the Diffserv codepoint (DSCP) and ECN
fields. 

just a suggestion as a technical contributor.

dbh

> From: Toby Moncaster [mailto:[email-masked]] 
> Sent: Monday, December 13, 2010 1:15 PM
> To: 'David Harrington'; 'Tom Taylor'
> Cc: 'pcn'
> Subject: RE: [PCN] Response to AD Review: 
> draft-ietf-pcn-sm-edge-behaviour-04
> 
> 
> 
> > > mentioned. Since this is used in formulae, that could be
important
> > to

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 13 Dec 2010 19:31:15 -0000

> From: David Harrington [mailto:[email-masked]]
> Sent: 13 December 2010 19:03
> To: 'Toby Moncaster'; 'Tom Taylor'
> Cc: 'pcn'
> Subject: RE: [PCN] Response to AD Review: draft-ietf-pcn-sm-edge-
> behaviour-04
> 
> Hi,
> 

How about:

* PCN-traffic, PCN-packets, PCN-BA. [RFC5559] defines these as:

Which makes it clearer that the formal definition is in RFC5559...

It might also be helpful to include a list of defined terms that have been
used in the document and their normative source after the definitions
section. I know it takes some time, but it seemed to work well in RFC5696
(where a similar approach was used for the list of abbreviations).

Toby

---

From: Tom Taylor <[email-masked]>
Date: Mon, 13 Dec 2010 16:47:09 -0500

"PCN-packets" is defined in RFC 5559. So, I discover, is "PCN-traffic". 
What I will do is list the RFC 5559 terms used at the beginning of the 
terminology section.

[snip]

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 14 Dec 2010 10:26:29 -0000

One comment

> Tom Taylor
> Sent: 13 December 2010 16:07
> To: David Harrington
> Cc: pcn
> Subject: [PCN] Response to AD Review: draft-ietf-pcn-sm-edge-behaviour-
> 04
> 

<SNIP>

I personally feel we don't need to tag the differences. Certainly eliminate
any unnecessary textual differences, but if you start tagging things you may
end up confusing developers, many of whom don't speak English as a first
language... My suggestion is put in the paragraph explaining that the two
documents are similar but omit the tagging. Hopefully these can go through
rfc-editor as a pair and get consecutive numbers which will make it easier
for people to realise they are related docs...

Toby

---

From: Tom Taylor <[email-masked]>
Date: Tue, 14 Dec 2010 09:15:13 -0500

How about a compromise: leave the tags in for review, but have an RFC 
Editor's note calling for their removal (and removal of the explanatory 
paragraph) before publication.

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 14 Dec 2010 14:18:09 -0000

Sounds extremely sensible to me!

> Sent: 14 December 2010 14:15
> To: Toby Moncaster
> Cc: 'David Harrington'; 'pcn'
> >>    a) Add the following paragraph at the end of Section 1 (CL
> version
> >> shown):
> >>