Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 7 Oct 2008 09:03:26 +0200

Steve,

I support pcn-architecture-06 as is.

My personal take on the terminology is that it is not wrong as is. Apart from that, having a stable terminology increases readbility of documents significantly. If it comes to the "rate and threshold terminology", PCN architecture changed terminology almost with every second draft in the past (I don't blame Phil for this). I'm not really interested in having to read contemporary architecture versions to understand any line in contemporary drafts and presentations of the PCN WG. It is further not nice to draft a document or a presentation and then change wording all the time as a new architecture version is published. I also was unhappy about Joe Babiarz presentation in Dublin, not because of the contents, but because of the terminology not folllowing the architecture draft. The presentation was hard to understand on the spot then and I need to spend extra time to learn individual author to WG terminology translations. As every author can claim the right to have his preferred terminology and my time is limited, I'll spend less time on reading drafts which are demanding already because of the applied individual terminology. Others having little time may do so too. I don't see the WG benefitting from this endless terminology debate and would like to come to an end now.

Regards,

Rudiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 29, 2008 6:49 PM
To: [email-masked]
Subject: [PCN] Second Last Call for draft-ietf-pcn-architecture

We will be running a brief (~1 week) last call on
draft-ietf-pcn-architecture-06.  This last call will end on Tuesday October
7.  Please send comments ASAP.

Diffs between -06 and -05 can be viewed at:

http://tools.ietf.org/rfcdiff

Use the following URLs to reference -05 and -06:

http://tools.ietf.org/id/draft-ietf-pcn-architecture-05.txt
http://tools.ietf.org/id/draft-ietf-pcn-architecture-06.txt

There are some known edits that have to be made before we can submit to the
IESG:

- Correct references to Internet Drafts to indicate "Work in Progress"
- Fix formatting errors detected by ID-nits

Regards,

// Steve

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Tue, 14 Oct 2008 08:35:48 -0400

By my reading of the last call comments, the only remaining issue where
we have some disagreement is surrounding the terminology proposed by
Michael Menth.

Does everyone agree that this is the last remaining issue?

If so, could we close on that this week?  Please send your commments to
the list ASAP.

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 15 Oct 2008 07:16:46 +0000

Hi Phil

I have read version 07 of the PCN architecture draft.
Thanks for trying to incorporate my last comments.
However, I think that some more clarifications are needed:

Comment_1:
Section 6, page 15:
Please remove the words "at most" that refers to the extension of
encodings:

Please change from:
"Extension encodings may be
      defined that, at most, use a second DSCP .."

INTO:

"Extension encodings may be
      defined that use a second DSCP .."

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

Comment_2:
Section 7.4, page 23:
Please add the following combination of words to the following sentence:
 - (others might be possible)
Please change from:
"As well as the functions covered above, other specific admission
   control functions need to be performed:"

INTO:
"As well as the functions covered above, other specific admission
   control functions need to be performed (others might be possible):"

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

Comment_3:
Section 7.4, page 23:

Please change from:
 "There are various possibilities for how the functionality could be
   distributed (we assume the operator would configure which is used):"

INTO:
 "There are various possibilities (others might be possible) for how the
functionality could be
   distributed (we assume the operator would configure which is used):"

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

Comment_4:
Section 7.5, page 24:
Please change from:

"As well as the functions covered above, other specific termination
   control functions need to be performed:"

INTO:
"As well as the functions covered above, other specific termination
   control functions need to be performed (others might be possible):"

Best regards,
Georgios

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 10:01:43 +0100

Thanks Georgios,

Comment 1:
I wrote in the document that extension encodings would either use the
baseline DSCP or "at most" a second dscp. You have in mind that an
extension encoding might use further DSCPs. I think 1 or 2 dscps
reflects all opinions that I've heard & all extension encodings proposed
so far.
Further, Steve's WG consensus call in March had
Q2: Should the PCN wg produce an experimental-track extension to the
    standards-track PCN scheme that requires another encoding state (for
    a total of three encoding states)?
Such an extension, I think, needs "at most a second DSCP".

So I'm inclined not to change the text.

I'm interested whether you have a specific idea for an extension
encoding that requires three DSCPs? (would like to see the proposal,
even if just a sketch)

Comments 2 (3 & 4 are very similar):
What's the reason behind this suggestion? The text describes the
admission control functions that have been talked about within the WG
(except for probing, which is covered later). Do you have specific
functions beyond ones that are already mentioned? Similarly for comment
3, do you have a particular example of another way that the admission
ctrl functionality could /should be distributed? 

I think if your motivation is that we should have as few restrictions as
possible - I'm inclined to disagree. The doc already talks about quite a
few different approaches for admission and termination. One of Lars's
criticisms of an earlier version of the architecture draft was that it
was too vague and hadn't narrowed down enough from the infinite spectrum
of possibilities. So I need more persuasion about comments 2-4.

Thanks
Phil/

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Georgios Karagiannis
{ Sent: 15 October 2008 08:17
{ To: [email-masked]
{ Subject: Re: [PCN] Second Last Call for draft-ietf-pcn-architecture
{ 
{ Hi Phil
{ 
{ 
{ I have read version 07 of the PCN architecture draft.
{ Thanks for trying to incorporate my last comments.
{ However, I think that some more clarifications are needed:
{ 
{ Comment_1:
{ Section 6, page 15:
{ Please remove the words "at most" that refers to the extension of
{ encodings:
{ 
{ Please change from:
{ "Extension encodings may be
{       defined that, at most, use a second DSCP .."
{ 
{ INTO:
{ 
{ "Extension encodings may be
{       defined that use a second DSCP .."
{ 
{ -----------------------------
{ 
{ 
{ Comment_2:
{ Section 7.4, page 23:
{ Please add the following combination of words to the following
sentence:
{  - (others might be possible)
{ Please change from:
{ "As well as the functions covered above, other specific admission
{    control functions need to be performed:"
{ 
{ INTO:
{ "As well as the functions covered above, other specific admission
{    control functions need to be performed (others might be possible):"
{ 
{ ------------------------------------
{ 
{ 
{ Comment_3:
{ Section 7.4, page 23:
{ 
{ Please change from:
{  "There are various possibilities for how the functionality could be
{    distributed (we assume the operator would configure which is
used):"
{ 
{ INTO:
{  "There are various possibilities (others might be possible) for how
the
{ functionality could be
{    distributed (we assume the operator would configure which is
used):"
{ 
{ -------------------------
{ 
{ 
{ Comment_4:
{ Section 7.5, page 24:
{ Please change from:
{ 
{ "As well as the functions covered above, other specific termination
{    control functions need to be performed:"
{ 
{ INTO:
{ "As well as the functions covered above, other specific termination
{    control functions need to be performed (others might be possible):"
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ 
{ 
{ 
{ 
{ 
{ 
{ 
{ On 10/14/2008, "Steven Blake" <[email-masked]> wrote:
{ 
{ >By my reading of the last call comments, the only remaining issue
where
{ >we have some disagreement is surrounding the terminology proposed by
{ >Michael Menth.
{ >
{ >Does everyone agree that this is the last remaining issue?
{ >
{ >If so, could we close on that this week?  Please send your commments
to
{ >the list ASAP.
{ >
{ >
{ >Regards,
{ >
{ >// Steve
{ >
{ >_______________________________________________
{ >PCN mailing list
{ >[email-masked]
{ >https://www.ietf.org/mailman/listinfo/pcn
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 15 Oct 2008 11:17:34 +0200

Hi Phil

Please see in line:

> From: [email-masked] [mailto:[email-masked]] 
> Sent: woensdag 15 oktober 2008 11:02
> To: [email-masked]; [email-masked]
> Subject: RE: [PCN] Second Last Call for draft-ietf-pcn-architecture
> 
> Thanks Georgios,
> 
> Comment 1:
> I wrote in the document that extension encodings would either 
> use the baseline DSCP or "at most" a second dscp. You have in 
> mind that an extension encoding might use further DSCPs. I 
> think 1 or 2 dscps reflects all opinions that I've heard & 
> all extension encodings proposed so far.
> I'm interested whether you have a specific idea for an 
> extension encoding that requires three DSCPs? (would like to 
> see the proposal, even if just a sketch)

Georgios: This is associated with the possibility of using the 
Affected marking encoding.
The answer on how many DSCPs will be used, will be asnwerwed by other
documents and not the PCN architecture draft.

> What's the reason behind this suggestion? The text describes 
> the admission control functions that have been talked about 
> within the WG (except for probing, which is covered later). 
> Do you have specific functions beyond ones that are already 
> mentioned? Similarly for comment 3, do you have a particular 
> example of another way that the admission ctrl functionality 
> could /should be distributed? 
> 
> I think if your motivation is that we should have as few 
> restrictions as possible - I'm inclined to disagree. The doc 
> already talks about quite a few different approaches for 
> admission and termination. One of Lars's criticisms of an 
> earlier version of the architecture draft was that it was too 
> vague and hadn't narrowed down enough from the infinite 
> spectrum of possibilities. So I need more persuasion about 
> comments 2-4.

Georgios: The comments 2,3, and 4 are related to the discussion 
regarding the HOSE model vs. ingress-egress-aggregate model.

The description in 7.4 and 7.5 talks only about the 
ingress-egress-aggregate model.

You may work out commnets 2,3 and 4 and rephrase the text as you want 
such that other models than ingress-egress-aggregate model are not excluded.

Best regards,
Georgios

> { From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of { Georgios Karagiannis { Sent: 15 October 2008 
> 08:17 { To: [email-masked] { Subject: Re: [PCN] Second Last 
> Call for draft-ietf-pcn-architecture { { Hi Phil { { { I have 
> read version 07 of the PCN architecture draft.
> { Please remove the words "at most" that refers to the 
> extension of { encodings:
> {
> { Please change from:
> {  "There are various possibilities (others might be 
> possible) for how the { functionality could be
> { >By my reading of the last call comments, the only 
> remaining issue where { >we have some disagreement is 
> surrounding the terminology proposed by { >Michael Menth.
> { >
> { >If so, could we close on that this week?  Please send your 
> commments to { >the list ASAP.
> { >
> { >
> { >Regards,
> { >
> { >// Steve
> { >

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 11:09:17 +0100

{ >
{ > Comment 1:
{ > I wrote in the document that extension encodings would either
{ > use the baseline DSCP or "at most" a second dscp. You have in
{ > mind that an extension encoding might use further DSCPs. I
{ > think 1 or 2 dscps reflects all opinions that I've heard &
{ > all extension encodings proposed so far.
{ > Further, Steve's WG consensus call in March had
{ > Q2: Should the PCN wg produce an experimental-track extension to the
{ >     standards-track PCN scheme that requires another encoding
{ > state (for
{ >     a total of three encoding states)?
{ > Such an extension, I think, needs "at most a second DSCP".
{ >
{ > So I'm inclined not to change the text.
{ >
{ > I'm interested whether you have a specific idea for an
{ > extension encoding that requires three DSCPs? (would like to
{ > see the proposal, even if just a sketch)
{ 
{ Georgios: This is associated with the possibility of using the
{ Affected marking encoding.
{ The answer on how many DSCPs will be used, will be asnwerwed by other
{ documents and not the PCN architecture draft.

Why would affected marking need a 3rd dscp? 2 dscps would seem to leave
plenty of room.

{ 
{ 
{ 
{ Georgios: The comments 2,3, and 4 are related to the discussion
{ regarding the HOSE model vs. ingress-egress-aggregate model.
{ 
{ The description in 7.4 and 7.5 talks only about the
{ ingress-egress-aggregate model.
{ 
{ You may work out commnets 2,3 and 4 and rephrase the text as you want
{ such that other models than ingress-egress-aggregate model are not
{ excluded.

Ok. I don't see why comment 3 (distribution of admission ctrl
functionality) applies. 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 15 Oct 2008 12:15:31 +0200

Hi Phil

Please see in line!

> Sent: woensdag 15 oktober 2008 12:09
> { > I wrote in the document that extension encodings would 
> either { > use the baseline DSCP or "at most" a second dscp. 
> You have in { > mind that an extension encoding might use 
> further DSCPs. I { > think 1 or 2 dscps reflects all opinions 
> that I've heard & { > all extension encodings proposed so far.
> { > Further, Steve's WG consensus call in March had { > Q2: 
> Should the PCN wg produce an experimental-track extension to the
> { > I'm interested whether you have a specific idea for an { 
> > extension encoding that requires three DSCPs? (would like 
> to { > see the proposal, even if just a sketch) { { Georgios: 
> This is associated with the possibility of using the { 
> { The answer on how many DSCPs will be used, will be 
> asnwerwed by other { documents and not the PCN architecture draft.
> 
> Why would affected marking need a 3rd dscp? 2 dscps would 
> seem to leave plenty of room.

Georgios: It depends on how the specification of the encoding states 
will be standardised. 

> 
> {
> {
> {
> { Georgios: The comments 2,3, and 4 are related to the 
> discussion { regarding the HOSE model vs. 
> { The description in 7.4 and 7.5 talks only about the { 
> { You may work out commnets 2,3 and 4 and rephrase the text 
> as you want { such that other models than 
> ingress-egress-aggregate model are not { excluded.
> 

Georgios: You are right. If comment_2 is worked out, than comment_3 will
also be worked out!

Best regards,
Georgios

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 11:21:10 +0100

{ > Why would affected marking need a 3rd dscp? 2 dscps would
{ > seem to leave plenty of room.
{ 
{ Georgios: It depends on how the specification of the encoding states
{ will be standardised.

Well, that's not really an answer.

{ >
{ > Ok. I don't see why comment 3 (distribution of admission ctrl
{ > functionality) applies.
{ 
{ Georgios: You are right. If comment_2 is worked out, than comment_3
will
{ also be worked out!
{ 
just to make sure I understand. If I add in comments 2 & 4, then you're
happy that I ignore comment 3.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 15 Oct 2008 13:27:57 +0200

Hi Phil

Please see in line!

> Sent: woensdag 15 oktober 2008 12:21
> { Georgios: It depends on how the specification of the 
> encoding states { will be standardised.
> 
> Well, that's not really an answer.]
Georgios: Yes, sorry! 
Affected marking needs one additional DCSP.

> 
> { >
> { > Ok. I don't see why comment 3 (distribution of admission 
> ctrl { > functionality) applies.
> {
> { Georgios: You are right. If comment_2 is worked out, than 
> comment_3 will { also be worked out!
> {
> just to make sure I understand. If I add in comments 2 & 4, 
> then you're happy that I ignore comment 3.
> 

Georgios: Yes if you add in comments 2 & 4, then you could ignore comment 3!

Best regards,
Georgios

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 12:31:09 +0100

{ Georgios: 
{ Affected marking needs one additional DCSP.

So I presume you're ok with the current text (which says one additional
dscp)?
Just checking!
Thanks
Phil.
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 15 Oct 2008 17:44:43 +0200

Hi Phil

Okay!

Best regards,
Georgios 

> Sent: woensdag 15 oktober 2008 13:31
> So I presume you're ok with the current text (which says one 
> additional dscp)?
> Just checking!
> Thanks
> Phil.
>