Subject: [PCN] How to discuss WG scoping decisions in an RFC?

From: Bob Briscoe <[email-masked]>
Date: Tue, 24 Jul 2007 22:05:31 +0100

Steve, Scott,

I'm nearly done writing a review of the PCN architecture. One issue I have 
is that there's a lot of text in there that I would class as WG process 
management text. Of two types:
i) scoping assumptions that are primarily charter-driven, but difficult to 
justify believably as assumptions about production networks - other than as 
a need to bite off part of a problem first, which isn't really a 
justification that should appear in a standards track RFC
ii) refs to docs that the charter requires, but that haven't been written 
yet, and may not have all been written before the first PCN RFC rolls off 
the production line.

This is natural for the first drafts of a WG, but surely we won't be able 
to submit RFCs like this.

ii) is relatively easy. where refs don't exist yet I assume authors should 
change all the inline text about planned docs to Editorial Notes, to remind 
everyone that these need to be added before it can go to RFC.

i) is more difficult. My working assumption is that RFCs have to be written 
to stand separately from the WG and process that created them. They exist 
for all time and charters change. So is the appropriate style to adopt 
charter scoping assumptions with suitable text written as if we believe 
them in their own right, rather than "because the charter says so"?

This particularly affects section 3 of 
draft-eardley-pcn-architecture-00.txt for things like emergency use being 
out of scope, or to a lesser extent the single-domain assumption.

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

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

---

From: Steven Blake <[email-masked]>
Date: Tue, 24 Jul 2007 17:27:40 -0400

> out of scope, or to a lesser extent the single-domain assumption.

draft-eardley-pcn-architecture-00 is not a working group document.  If
the authors ask to have this draft approved as a WG document then these
are useful comments to raise.

Regarding emergency use: the charter says:

  (D) flows may have different precedence, but the applicability
      of the PCN mechanisms for emergency use (911, GETS, WPS,
      MLPP, etc.) is out of scope

This could be interpreted in more than one way, but I interpret this as
saying that PCN-specific mechanisms will not take flow precedence into
account.  Which is a different than saying that PCN cannot be used with
flow setup protocols/mechanisms that take flow precedence into account.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: Michael Menth <[email-masked]>
Date: Wed, 25 Jul 2007 11:13:47 +0200

> flow setup protocols/mechanisms that take flow precedence into account.

As soon as we have multiple PCN classes it might be useful to think 
about flow precedence especially with regard to admission and 
termination priority. Equal treatment of flows means that a highly 
critical telemedicine application has the same probability to be 
terminated as a "relatively" uncritcical VoIP call in case of a 
disaster. I read the passage in the way that it's not our job to define 
mechanisms for emergency use, but it is not prohibited to extend PCN 
towards multiple classes with different requirements although this is 
not the first thing to do.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 25 Jul 2007 13:12:28 +0100

Steve & Michael (responses to both inline),

At 10:13 25/07/2007, Michael Menth wrote:

>>>I'm nearly done writing a review of the PCN architecture. One issue I 
>>>have is that there's a lot of text in there that I would class as WG 
>>>process management text. Of two types:
>>>i) scoping assumptions that are primarily charter-driven, but difficult 
>>>to justify believably as assumptions about production networks - other 
>>>than as a need to bite off part of a problem first, which isn't really a 
>>>ii) refs to docs that the charter requires, but that haven't been 
>>>written yet, and may not have all been written before the first PCN RFC 
>>>rolls off the production line.
>>>
>>>This is natural for the first drafts of a WG, but surely we won't be 
>>>able to submit RFCs like this.
>>>
>>>ii) is relatively easy. where refs don't exist yet I assume authors 
>>>should change all the inline text about planned docs to Editorial Notes, 
>>>to remind everyone that these need to be added before it can go to RFC.
>>>
>>>i) is more difficult. My working assumption is that RFCs have to be 
>>>written to stand separately from the WG and process that created them. 
>>>They exist for all time and charters change. So is the appropriate style 
>>>to adopt charter scoping assumptions with suitable text written as if we 
>>>believe them in their own right, rather than "because the charter says so"?
>>>
>>>draft-eardley-pcn-architecture-00.txt for things like emergency use 
>>>being out of scope, or to a lesser extent the single-domain assumption.
>>>
>>

Steve, I think you might have misunderstood my intent. I'm asking for 
advice on how to write a good I-D. All I-Ds should be written with the 
intent of becoming WG items. I don't think there's any need to only answer 
this question after an I-D becomes a WG item.

If anyone is writing an RFC without the intent for it to become and RFC, 
then it deserves to be ignored.

>As soon as we have multiple PCN classes it might be useful to think about 
>flow precedence especially with regard to admission and termination 
>priority. Equal treatment of flows means that a highly critical 
>telemedicine application has the same probability to be terminated as a 
>"relatively" uncritcical VoIP call in case of a disaster. I read the 
>passage in the way that it's not our job to define mechanisms for 
>emergency use, but it is not prohibited to extend PCN towards multiple 
>classes with different requirements although this is not the first thing to do.

Michael, just to warn against your use of the word 'extend' PCN.

For the avoidance of doubt, I think Steve's saying it is NOT in scope to 
extend PCN towards multiple classes with different requirements, but it is 
in scope for PCN to use (ie refer out to) other mechanisms that satisfy 
different emergency reqs, and similarly I guess it would be in scope to 
prove PCN doesn't stop these other mechanisms working.

If I'm right, the txt in this arch draft is misleading and should be 
changed. The _applicability_ of PCN mechs for emergency use is in scope, 
but PCN-specific mechs for emergency use are out of scope.

Bob

---

From: Michael Menth <[email-masked]>
Date: Wed, 25 Jul 2007 14:54:16 +0200

Hi Bob,

Bob Briscoe wrote:
>> disaster. I read the passage in the way that it's not our job to 
>> define mechanisms for emergency use, but it is not prohibited to 
>> extend PCN towards multiple classes with different requirements 
>> although this is not the first thing to do.
>
> For the avoidance of doubt, I think Steve's saying it is NOT in scope 
> to extend PCN towards multiple classes with different requirements, 
> but it is in scope for PCN to use (ie refer out to) other mechanisms 
> that satisfy different emergency reqs, and similarly I guess it would 
> be in scope to prove PCN doesn't stop these other mechanisms working.
>
> changed. The _applicability_ of PCN mechs for emergency use is in 
> scope, but PCN-specific mechs for emergency use are out of scope.

Sorry for using the word "extend", but I'm not sure whether I understand 
your answer correctly. We had the discussion about coexistence of 
several PCN- and non-PCN classes already several times on the list and 
it seemed to me that is an unsolved issue so far. When I say "extend 
PCN" I mean adapting the currently discussed single-PCN-class mechanisms 
to work in a multi-class environment with a pre-defined number of PCN 
classes. I do not talk about extending PCN for the need of specific 
applications.

The existence of multiple PCN classes has some impact on encoding and 
possibly also on metering and marking, so this is a question that should 
be discussed before encoding is decided. As far as I can remember the 
general view was that the charter does not forbid several PCN classes, 
but it's not the first thing to be done. Are we in line or is your view 
that there is and will be only a single PCN class that is coupled with a 
single PHB? Maybe this is an issue for discussion at the meeting, at 
least to me, the answer of that question is not clear.

Regards,

Michael

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 25 Jul 2007 17:37:38 +0100

Michael,

Whatever I said, I meant to include what you're saying. Thanks for clarifying.

Yes, what you say has major implications on the PCN encoding. If we used 4 
DSCPs to encode PCN states, but there were already 2 DSCPs for MLPP, we 
would need 4x2 DSCPs. Whereas if we used the ECN field for PCN states, it 
is orthogonal to the DS field.

Bob

At 13:54 25/07/2007, Michael Menth wrote:
>>extend PCN towards multiple classes with different requirements, but it 
>>is in scope for PCN to use (ie refer out to) other mechanisms that 
>>satisfy different emergency reqs, and similarly I guess it would be in 
>>scope to prove PCN doesn't stop these other mechanisms working.
>>
>your answer correctly. We had the discussion about coexistence of several 
>PCN- and non-PCN classes already several times on the list and it seemed 
>to me that is an unsolved issue so far. When I say "extend PCN" I mean 
>adapting the currently discussed single-PCN-class mechanisms to work in a 
>multi-class environment with a pre-defined number of PCN classes. I do not 
>talk about extending PCN for the need of specific applications.
>
>general view was that the charter does not forbid several PCN classes, but 
>it's not the first thing to be done. Are we in line or is your view that 
>there is and will be only a single PCN class that is coupled with a single 
>PHB? Maybe this is an issue for discussion at the meeting, at least to me, 
>the answer of that question is not clear.
>
>Regards,
>
>Michael
>
>
>>
>>
>>Bob
>>
>>
>>>Regards,
>>>
>>>    Michael
>>>
>>>>
>>>>Regards,
>>>>