Subject: Re: [NSIS] Working Group Last Call: Y.1541 QOSM

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 15 Oct 2008 09:51:57 +0300 (EEST)

Dear all,

I've been waiting to get at least some late reviews on the draft, but no 
such luck. Let me know if some of you are still in the review process. 

Even a simple "I've read the draft and have no concerns" would be an 
important sign to the WG that the document is ready to proceed.

Regards,
Jukka

On Mon, 22 Sep 2008, Jukka MJ Manner wrote:

> 
> Dear all,
> 
> This marks the beginning of a two week WGLC for
> 
> "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes"
> 
> http://tools.ietf.org/wg/nsis/draft-ietf-nsis-y1541-qosm/
> 
> Please review the document and send your comments by October 6th.
> 
> Regards,
> Jukka & Martin
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 21 Oct 2008 10:29:40 +0200

Dear all

I have read the v06 version of the y1541-qosm draft and compared it with
version  v05.
I think that the updates associated with the included example are useful! 

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jukka MJ Manner
> Sent: woensdag 15 oktober 2008 8:52
> To: NSIS Working Group
> Subject: Re: [NSIS] Working Group Last Call: Y.1541 QOSM
> 
> 
> Dear all,
> 
> I've been waiting to get at least some late reviews on the 
> draft, but no such luck. Let me know if some of you are still 
> in the review process. 
> 
> Even a simple "I've read the draft and have no concerns" 
> would be an important sign to the WG that the document is 
> ready to proceed.
> 
> Regards,
> Jukka
>

---

From: "Martin Stiemerling" <[email-masked]>
Date: Sat, 25 Oct 2008 17:22:19 +0200

[writing with chair's hat off]

I have read the draft and fine with it.

Thanks,

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jukka MJ Manner
> Sent: Wednesday, October 15, 2008 8:52 AM
> To: NSIS Working Group

---

From: Xiaoming Fu <[email-masked]>
Date: Sun, 26 Oct 2008 23:11:58 +0100

I agree this is good to go, with two minor comments:
"less Than" --> "less than"

In [QSPEC-20]:
The  composition rule for the <Path PLR> parameter is summation with a
    clamp on the maximum value (this assumes sufficiently low PLR values
    such that summation error is not significant, however a more accurate
    composition function is specified in clause 8 of [Y.1541]).
But currently [Y.1541-06] does not have clause 8 to explain this 
composition function. --> a need to align?

Xiaoming

---

From: Jukka Manner <[email-masked]>
Date: Mon, 27 Oct 2008 08:42:26 +0200

Dear all,

After considerable extra time, we can conclude the WGLC on the Y.1541. 
There were no objections, only supporting comments.

Authors, please update the draft and take into account the following 
items I found in my own chair's review:

- Some of the references hyperlinks do not work in the html version

- The text looks a bit weird since you have typically twice the 
reference, e.g., "As stated above, [Y.1541] [Y.1541] is ..."

- Is parameter M measured in octets? Please specify explicitly. Same for 
Bp, actually.

- Restoration priority: you describe some candidate time values that are 
based on current technology. Wouldn't it be good to add this 
time-to-restore as an optional value in the object, say, instead of 
having 42 bits unused, this field could indicate in milliseconds how 
fast the restoration SHOULD be. The network can of course decide 
otherwise. A value of all 0's would mean "Unspecified". This would allow 
the spec to be future proof. The values you give in the spec could be 
default values to be used.

Regards,
Jukka

---

From: Jukka Manner <[email-masked]>
Date: Mon, 27 Oct 2008 08:45:40 +0200

Dear all,

This message starts the Working Group Last Call on the RMD QOSM.

http://tools.ietf.org/wg/nsis/draft-ietf-nsis-rmd/

Please submit your comments within two weeks, by Monday November 10th.

Regards,
Jukka

ps. And, please people, be a bit more active. Thanks.
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Al Morton <[email-masked]>
Date: Mon, 27 Oct 2008 14:50:16 -0400

Xiaoming,

Thanks for your review and comments.

regarding

At 06:11 PM 10/26/2008, Xiaoming Fu wrote:

In [QSPEC-20]:

The  composition rule for the <Path PLR> parameter is
summation with a

clamp on the maximum value (this assumes sufficiently low
PLR values

such that summation error is not significant, however a more
accurate

composition function is specified in clause 8 of
[Y.1541]).

The actual text of Recommendation Y.1541 has a clause 8,

so there's no problem.  Perhaps you were thinking of the

Y.1541 QOSM draft, where clause 8 is the reference section,

but it also uses a different reference tag:

[
Y.1541-QOSM] Ash, J., et al., "Y.1541-QOSM -- Y.1541 QoS Model
for
Networks Using Y.1541 QoS Classes," work in progress.

Al

---

From: Al Morton <[email-masked]>
Date: Mon, 27 Oct 2008 16:49:22 -0400

Hi Jukka,

thanks for your suggestions, see below...

At 02:42 AM 10/27/2008, Jukka Manner wrote:
>...Authors, please update the draft and take into account the 
>following items I found in my own chair's review:
>

This seems to be a quirk in the html-conversion routine
when working from plain text.  The html version I created
from the .xml file has working links, so I'll try to replace
the auto-generated html with my own html file...

>reference, e.g., "As stated above, [Y.1541] [Y.1541] is ..."

yes, fixed.

>- Is parameter M measured in octets? Please specify explicitly. Same 
>for Bp, actually.

OK, done.

>- Restoration priority: you describe some candidate time values that 
>are based on current technology. Wouldn't it be good to add this 
>otherwise. A value of all 0's would mean "Unspecified". This would 
>allow the spec to be future proof. The values you give in the spec 
>could be default values to be used.

I discussed this with a key co-author, and we'll make the following
changes:

Add Reference to Rec. Y.2172 for short descriptions of standardized
restoration priorities.

Clarify that the Reserved octets (24 bits) may be used for a restoration
time specification, or an extent (like probability) of restoration,
or both of these, (or these and something else, etc.).
IOW, the unused Reserved Field is intended for the sort of thing you
suggest, but we're not ready to give all the space to restoration
time yet...

hope this helps, the draft is on the way,
Al

---

From: Jukka Manner <[email-masked]>
Date: Tue, 28 Oct 2008 08:25:26 +0200

Hi Al,

Sounds good.

br,
Jukka

---

From: Al Morton <[email-masked]>
Date: Wed, 29 Oct 2008 08:19:18 -0400

At 02:25 AM 10/28/2008, Jukka Manner wrote:
>>...
>>>...

Unfortunately, the feature that allows folks to upload
alternate/additional files has been removed, AFAICT.

Al

---

From: <[email-masked]>
Date: Thu, 30 Oct 2008 13:13:05 -0000

Hi,

A few comments (certainly not a full review!)

S2 terminology
I think these should be functional definitions. Eg if the ingress node
is congested your definition implies that it doesn't congestion mark.
DiffServ (& PCN) use functional definitions

I think you should add a definition of NSIS aware & unaware. I found it
quite confusing. At the moment when one of these terms is mentioned the
doc often gives a semi-definition. Nsis unaware seems to mean something
like, unaware of nsis signalling, but some sorts of nsis state & rmd ops
are possible. You can tell from the last sentence that I didn't get a
good view of what it meant! For instance I found S4.3.2 , the 2 paras
about probing, confusing. 

S3.1 top of page 7: measurement-based, "once an admission decision is
made, no record need be kept". Surely the ingress needs to keep a
record, because it has to police

3.2.3 first para
"The reason for this.." I didn't understand your reasoning. I think this
is something to do with the <QoS Desired> parameter, which you assumed
I'd know what it does.

3.2.3 
6 different possible signalling schemes is a lot for one document? 
Items 3 & 4 form a pair (different sever congestion operation) as do
items 5 & 6. but items 1 & 2 don't - why? 
Wasn't sure what "per aggregate" meant (4.3.1 didn't help) - I guess
this is just standard nsis terminology?

PCN is only mentioned in one sentence in S3.2.3. do you (or rather the
iesg) think this is enough? (I'm personally ok with this level.)

4.6.1.6.2.1
"one DSCP for severe congestion indication for each of the AF  classes".
Contradicts 3.2.3 where say 0 or 1 AF class?

S5 security
Should there be separate considerations for your 6 different possible
signalling schemes?
Why have you got SHOULDs? Should they be MUSTs?

App A - good that this is now an example in Appendix ( I seem to
remember it was in the main text before)

Fig A.1 - why is there no event for moving from severe cong state to
cong notification state.

Best wishes,
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ Jukka Manner
{ Sent: 27 October 2008 06:46
{ To: NSIS Working Group
{ Subject: [NSIS] Working Group Last Call: RMD QOSM
{ 
{ 
{ Dear all,
{ 
{ This message starts the Working Group Last Call on the RMD QOSM.
{ 
{ http://tools.ietf.org/wg/nsis/draft-ietf-nsis-rmd/
{ 
{ Please submit your comments within two weeks, by Monday November 10th.
{ 
{ Regards,
{ Jukka
{ 
{ ps. And, please people, be a bit more active. Thanks.
{ _______________________________________________
{ nsis mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: <[email-masked]>
Date: Thu, 30 Oct 2008 15:32:17 -0000

Re-sending (sorry if duplicate, but something seems wrong with my email)

{ -----Original Message-----
{ From: Eardley,PL,Philip,CXR9 R
{ Sent: 30 October 2008 13:13
{ To: 'Jukka Manner'; NSIS Working Group
{ Subject: RE: [NSIS] Working Group Last Call: RMD QOSM
{ 
{ Hi,
{ 
{ A few comments (certainly not a full review!)
{ 
{ S2 terminology
{ I think these should be functional definitions. Eg if the ingress node
is
{ congested your definition implies that it doesn't congestion mark.
{ DiffServ (& PCN) use functional definitions
{ 
{ I think you should add a definition of NSIS aware & unaware. I found
it
{ quite confusing. At the moment when one of these terms is mentioned
the
{ doc often gives a semi-definition. Nsis unaware seems to mean
something
{ like, unaware of nsis signalling, but some sorts of nsis state & rmd
ops
{ are possible. You can tell from the last sentence that I didn't get a
good
{ view of what it meant! For instance I found S4.3.2 , the 2 paras about
{ probing, confusing.
{ 
{ S3.1 top of page 7: measurement-based, "once an admission decision is
{ made, no record need be kept". Surely the ingress needs to keep a
record,
{ because it has to police
{ 
{ 3.2.3 first para
{ "The reason for this.." I didn't understand your reasoning. I think
this
{ is something to do with the <QoS Desired> parameter, which you assumed
I'd
{ know what it does.
{ 
{ 3.2.3
{ 6 different possible signalling schemes is a lot for one document?
{ Items 3 & 4 form a pair (different sever congestion operation) as do
items
{ 5 & 6. but items 1 & 2 don't - why?
{ Wasn't sure what "per aggregate" meant (4.3.1 didn't help) - I guess
this
{ is just standard nsis terminology?
{ 
{ PCN is only mentioned in one sentence in S3.2.3. do you (or rather the
{ iesg) think this is enough? (I'm personally ok with this level.)
{ 
{ 4.6.1.6.2.1
{ "one DSCP for severe congestion indication for each of the AF
classes".
{ Contradicts 3.2.3 where say 0 or 1 AF class?
{ 
{ S5 security
{ Should there be separate considerations for your 6 different possible
{ signalling schemes?
{ Why have you got SHOULDs? Should they be MUSTs?
{ 
{ App A - good that this is now an example in Appendix ( I seem to
remember
{ it was in the main text before)
{ 
{ Fig A.1 - why is there no event for moving from severe cong state to
cong
{ notification state.
{ 
{ Best wishes,
{ phil
{ 
{ { -----Original Message-----
{ { From: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ { Jukka Manner
{ { Sent: 27 October 2008 06:46
{ { To: NSIS Working Group
{ { Subject: [NSIS] Working Group Last Call: RMD QOSM
{ {
{ {
{ { Dear all,
{ {
{ { This message starts the Working Group Last Call on the RMD QOSM.
{ {
{ { http://tools.ietf.org/wg/nsis/draft-ietf-nsis-rmd/
{ {
{ { Please submit your comments within two weeks, by Monday November
10th.
{ {
{ { Regards,
{ { Jukka
{ {
{ { ps. And, please people, be a bit more active. Thanks.
{ { _______________________________________________
{ { nsis mailing list
{ { [email-masked]
{ { https://www.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis