Re: Working Group Last Call: Y.1541 QOSM

Hi Al,

Sounds good.

br,
Jukka

Al Morton wrote:
> 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:
>>
>> - Some of the references hyperlinks do not work in the html version
> 
> 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...
> 
> 
>> - The text looks a bit weird since you have typically twice the 
>> 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 
>> 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.
> 
> 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
> 
> 
>