[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21
Hi Jerry,
I suggest changes looks fine unless commented. I have removed everything
where your response resolves the issues. Looking forward to a new version.
Gerald Ash skrev:
>> --- On Fri, 10/2/09, Magnus Westerlund <magnus.westerlund at ericsson.com>
>> wrote:
>> 10. Section 3.3.2: What is the definition of path error ratio?
>
> Per the definition in Y.1540 and Y.1541:
> "Packet error ratio is the ratio of total errored IP packet outcomes to
> the total of successful IP packet transfer outcomes plus errored IP
> packet outcomes in a population of interest, with a resolution of at
> least 10–9. If lesser resolution is available in a value, the unused
> digits shall be set to zero."
> Will also add that the number of errored packets observed is directly
> related to the confidence in the result.
Thanks, please add a reference to the definition.
>
>> 11. This may seem out of context but I do want to know the answer to how
>> the situation is handled when QNI and QNR are neighbors on a non QoS
>> enabled network.
>
> What "situation" are you referring to here? IMO you can't have a QNI
> and QNR in a "non QoS enabled network". By definition, a QNI and QNR
> are only defined in an NSIS enabled network (i.e., a QoS enabled network).
I am asking what is happening in these cases where a QNI has the QNR as
peer and there are no network support. Clearly you will not get any QoS,
but is it clear to both QNI and QNR that this is the situation?
>
>> 15. Section 5.1.1:
>> " Length: The total length of the QSPEC excluding the common header"
>>
>> Please make it clear that you count in 32-bit words (?) and add the "."
>> at the end of the sentence.
>
> "Length" is defined at the beginning of Section 5.1 as follows:
> " o Length has the units of 32-bit words, and measures the length of
>
> Value. If there is no Value, Length=0. The Object length
>
> excludes the header."
>
>
>
> The sentence you quote above in Section 5.1.1 will also be clarified as
> follows:
>
> " Length: The total length of the QSPEC (in 32-bit words) excluding
> the common header"
>
good, because it is not obvious that the text in 5.1 applies to the
common header as it isn't a TLV structure.
>
>> 19. Section 5.2.3: The referenced documents does not define Path
>> latency, only minimal path latency. Not obvious that they are the same,
>> for example from a perspective of queuing delay or link ARQ.
>
>
>
> The intention of the Path Latency parameter is the same as the Minimal
> Path Latency parameter defined in Section 3.4 of RFC 2215. Note that it
> also says in RFC 2215:
>
>
>
> "The purpose of this parameter is to provide a baseline minimum path
> latency for use with services which provide estimates or bounds on
> additional path delay, such as Guaranteed [RFC 2212].. Together with
> the queuing delay bound offered by Guaranteed and similar services,
> this parameter gives the application knowledge of both the minimum
> and maximum packet delivery delay."
>
>
>
> This is also the intent of the parameter for use in the QSPEC.
>
Yes, but nit-picking here I do think you could make it clear that the
QSPEC parameter is defined as "minimal path latency in RFC 2215".
>
>> 27. Section 7.. QSPEC Procedures. This table is so confusing, I can't get
>> my head around what code point space is registered. And if there are a
>> second dimension for certain values and in that case which that is.
>
>
>
> The QSPEC Procedures object being registered by IANA specifications in
> Section 7 is specified in Section 5.1.1 (Common Header Format).
> The code point space consists of a Message Sequence sub-parameter and an
> Object Combination sub-parameter. Section 4.3 explains the Message
> Sequence and Object Combination sub-parameters. Object Combinations 0,
> 1, and 2 are explained in Section 4.3.1, 4.3.2, and 4.3.3,
> respectively. Tables 1, 2, and 3 in Section 4.3 assign the Message
> Sequence ID to Object Combinations 0, 1, and, 2, respectively. There is
> an error to be corrected in the IANA specifications: Object Combination
> 2 (Section 4.3.3) has only one Message Sequence ID, not 3 (this will be
> corrected. Hopefully this explains whatever confusion there is here.
>
I think one of the bigger issues is that it is compact without any line
spacing or indentation to make the structure clear.
>
>> 28. References: Can you please ensure that there is a blank line between
>> each reference. Now it is very difficult to read the list.
>
>
>
> OK
>
>
>
>> Also, making
>> the reference using a hanging style makes it easier to find the
>> reference identifiers.
>
>
>
> Not sure what you mean by "hanging style"? Do you mean to indent the
> references, e.g.,
>
>
>
> [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd
> Generation Partnership Project; Technical Specification Group
> Services and System Aspects; enhanced Multi Level
> Precedence and
> Preemption service (eMLPP) - Stage 1 (Release 7).
>
>
> If so, OK.
Yes, that is what I mean.
Cheers
Magnus Westerlund
IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------