Subject: RE: [NSIS] draft-qosmodel-controlledload-04

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 4 Jul 2006 13:22:46 +0200

Hi Rüdiger and All, 

The mapping should be defined, the question is where. The current QSPEC assumes that it is defined in the QoS model drafts, since the mapping may depends on the QoS models. 

Best regards, Attila

> -----Original Message-----
> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: Tuesday, July 04, 2006 9:08 AM
> To: [email-masked]; Attila Báder (IJ/ETH)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [NSIS] draft-qosmodel-controlledload-04
> 
> 
> Bernd, Attila,
> 
> Attila raised concerns about mappings of mandatory parameters 
> being difficult. Bernd proposed a definition of mappings 
> (omitted here) and concludes:
> 
> |The only problem I see: Do I know the QOSM of my neighbor 
> |domain? Do I have to consider this when sending the 
> |initiator QSPEC?
> 
> What you discuss is an interworking or a partial interworking 
> between different services. Interworkings are common in 
> the telephony world. It is important to be aware where they 
> happen and to know their characteristics, meaning they need 
> to be specified. 
> 
> Unspecified mappings of parameters should therefore not occur. 
> The spec should say that. If a parameter isn't interpreted 
> and this is a "specified behaviour" known to all parties,
> that may still be tolerable, I think.
> 
> Regards,
> 
> Rüdiger
> 
> 
> |
> |Attila Báder (IJ/ETH) wrote:
> |> Hi All,
> |> 
> |> If "ignore" is not a type interpretation, I also think that 
> |> it should be reformulated.
> |> 
> |> In general, to understend mandatory parameters that is not 
> |> used in a local QoSM, I see less problem. If a QOSM has to 
> |> fill in mandatory parameters that is not used in this QOSM, 
> |> seems to be more difficult.
> |> 
> |> Best regards, Attila
> |> 
> |> 
> |>>-----Original Message-----
> |>>From: Hannes Tschofenig [mailto:[email-masked]]
> |>>Sent: Monday, July 03, 2006 4:37 PM
> |>>To: Georgios Karagiannis
> |>>Cc: 'Ash, Gerald R (Jerry), ALABS'; Attila Báder (IJ/ETH);
> |>>[email-masked]; 'Kappler Cornelia'
> |>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> |>>
> |>>
> |>>Hi Georgios,
> |>>
> |>>please find my comment below:
> |>>
> |>>Georgios Karagiannis wrote:
> |>>
> |>>>Hi Jerry 
> |>>>
> |>>>Regarding your last point:
> |>>>
> |>>>
> |>>>>>Hannes:
> |>>>>>Do you think it is awfully realistic for all QNEs to 
> |>>
> |>>understand all 
> |>>
> |>>>>>mandatory parameters? I could imagine that Attila and 
> |>>>>>Georgios are not 
> |>>>>>going to implement stateless interior QNEs in such a way 
> |that they 
> |>>>>>understand all the mandatory QSPEC parameters. In fact they 
> |>>>>>don't have 
> |>>>>>todo it since only edge routers are likely to ever see QoS 
> |>>>>>NSLP messages 
> |>>>>>that contain QOSM IDs that they do not understand (otherwise 
> |>>>>>something 
> |>>>>>go terribly wrong).
> |>>>
> |>>>
> |>>>>Jerry: It is up the RMD authors to specify how they want RMD 
> |>>>>
> |>>>>
> |>>>>>to behave wrt mandatory parameters (and obtain rough 
> |>>>>>consensus, of course).  That is, if a mandatory parameter 
> |>>>>>is remapped and not strictly interpreted, the remapping 
> |>>>>>must be specified in the QOSM specification document.  
> |>>>>>Otherwise, the QOSM must strictly interpret the mandatory 
> |>>>>>parameters that are not remapped, if they are populated 
> |by the QNI.
> |>>>>>There are no restrictions on how the remapping must be done, 
> |>>>>>it can be as simple as necessary (but no simpler).
> |>>>
> |>>>
> |>>>Georgios:
> |>>>Jerry, I think that the point raised by Hannes is related to
> |>>>how the QNE's interior to the RMD domain will have to 
> comply to the
> |>>>mandatory  descriptions specified in the QSPEC template. 
> |>>>An interior QNE (in RMD-QOSM) will not process 
> |>>>the end to end QSpec. The only QSpec that will be 
> processed by the 
> |>>>interior QNE is the RMD Qsepc that is initiated by the 
> |>>>ingress node (i.e., QNI for the RMD local session). 
> |>>>Note that the above observation is valid for all local QOSMs.
> |>>>However, the above is not allowed due to the following 
> text that is 
> |>>>included in the QSpec template draft:
> |>>>
> |>>>"A QNE MUST interpret all mandatory parameters from this 
> |>>
> |>>document even 
> |>>
> |>>>if it does not support the received QoS NSLP message with the 
> |>>>indicated QOSM."
> |>>>
> |>>>Therefore, in my opinion it is required to modify the above 
> |>>
> |>>sentence in
> |>>
> |>>>something like:
> |>>>
> |>>>"A QNE SHOULD interpret all mandatory parameters from this 
> |>>
> |>>document even 
> |>>
> |>>>if it does not support the received QoS NSLP message with the 
> |>>>indicated QOSM. A QNE that supports a local QOSM, does not 
> |>>
> |>>have to interpret
> |>>
> |>>>all mandatory parameters carried by a QSpec that was 
> |>>
> |>>generated by a QNI 
> |>>
> |>>>located outside the domain that supports the given local QOSM." 
> |>>
> |>>Something along these lines would probably be more 
> |realistic, I guess.
> |>>
> |>>Ciao
> |>>Hannes
> |>>
> |>>
> |>>>Best regards,
> |>>>Georgios
> |>>>
> |>>>-----Original Message-----
> |>>>From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> |>>>Sent: maandag 3 juli 2006 2:03
> |>>>To: Hannes Tschofenig
> |>>>Cc: Ash, Gerald R (Jerry), ALABS; Attila Báder (IJ/ETH); 
> |>>
> |>>[email-masked];
> |>>
> |>>>Kappler Cornelia
> |>>>Subject: RE: [NSIS] draft-qosmodel-controlledload-04
> |>>>
> |>>>Hi Hannes,
> |>>>
> |>>>See below. 
> |>>>
> |>>>
> |>>>
> |>>>>-----Original Message-----
> |>>>>From: Hannes Tschofenig [mailto:[email-masked]]
> |>>>>Sent: Saturday, July 01, 2006 4:26 PM
> |>>>>To: Ash, Gerald R (Jerry), ALABS
> |>>>>Cc: [email-masked]
> |>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> |>>>>
> |>>>>Hi Jerry,
> |>>>>
> |>>>>it is true that I haven't read the most recent QSPEC draft 
> |>>
> |>>when I sent 
> |>>
> |>>>>this mail. In the meanwhile I did. Please find a few 
> |comments below:
> |>>>>
> |>>>>Ash, Gerald R (Jerry), ALABS wrote:
> |>>>>
> |>>>>
> |>>>>>Hi Hannes,
> |>>>>>
> |>>>>>See below. 
> |>>>>>
> |>>>>>
> |>>>>>
> |>>>>>
> |>>>>>>-----Original Message-----
> |>>>>>>From: Hannes Tschofenig [mailto:[email-masked]]
> |>>>>>>Sent: Friday, June 30, 2006 8:43 AM
> |>>>>>>To: Bernd Schloer
> |>>>>>>Cc: [email-masked]
> |>>>>>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> |>>>>>>
> |>>>>>>Hi Bernd,
> |>>>>>>
> |>>>>>>Bernd Schloer wrote:
> |>>>>>>
> |>>>>>>
> |>>>>>>
> |>>>>>>>Hi,
> |>>>>>>>
> |>>>>>>>the first open issue in the appendix B is about what 
> to do with 
> |>>>>>>>mandatory QSPEC parameters which are not needed for CLS.
> |>>>>>>>
> |>>>>>>>Does a QOSM have to understand (and provide information 
> |>>
> |>>about) all 
> |>>
> |>>>>>>>mandatory parameters, even if they are not used?
> |>>>>>>
> |>>>>>>I think the question is wrong. What about the 
> following question:
> |>>>>>>"
> |>>>>>>Does a node that implements a particular QOSM has to 
> |>>
> |>>understand all 
> |>>
> |>>>>>>mandatory parameters listed in the QSPEC template draft
> |>>>>
> |>>>>(even if the
> |>>>>
> |>>>>
> |>>>>>>QOSM does not make use of them)?
> |>>>>>>"
> |>>>>>>The answer would be "YES" since the QSPEC template draft 
> |>>
> |>>says that 
> |>>
> |>>>>>>mandatory parameters have to be understood by every NSIS 
> |QoS node.
> |>>>>>>
> |>>>>>>There is only the question what "understands" means.
> |>>>>>
> |>>>>>
> |>>>>>IMO you need to more carefully read the QSPEC I-D 
> document.  All 
> |>>>>>mandatory QSPEC parameters that are populated in the 
> |QSPEC must be 
> |>>>>>interpreted by every QNE, which is explained in the QSPEC I-D:
> |>>>>>
> |>>>>>It says in Section 4.4.1 (Mandatory and Optional QSPEC
> |>>>>
> |>>>>. Parameters) of
> |>>>>
> |>>>>
> |>>>>>the QSPEC I-D
> |>>>>>http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt:
> |>>>>>
> |>>>>>"  Mandatory QSPEC parameters are treated as follows:
> |>>>>>
> |>>>>>  o A QNI SHOULD populate mandatory QSPEC parameters if
> |>>>>
> |>>>>.      applicable to
> |>>>>
> |>>>>
> |>>>>>    the underlying QOSM.
> |>>>>
> |>>>>I don't understand this sentence. What does it mean that a QNI 
> |>>>>"SHOULD"
> |>>>>populate parameters if applicable?
> |>>>
> |>>>
> |>>>It means that a QNI is not required to populate all 
> |>>
> |>>mandatory parameters.  A
> |>>
> |>>>QNI would only populated a mandatory parameter if is used 
> |>>
> |>>by the QOSM
> |>>
> |>>>supported by the QNI.
> |>>> 
> |>>>
> |>>>
> |>>>>>  o QNEs MUST interpret mandatory QSPEC parameters, if 
> signaled."
> |>>>>>
> |>>>>>Furthermore, it says in Section 4.2 (QSPEC Processing):
> |>>>>>
> |>>>>>"  a QNE
> |>>>>>  MUST at least interpret all the mandatory parameters in 
> |>>>>>  a QSPEC even
> |>>>>>  if it does not support the corresponding QOSM.
> |>>>>>
> |>>>>>  Mandatory parameters provide a minimal subset of parameters. A
> |>>>>>  QNE MUST either a) strictly interpret a mandatory 
> parameter, or
> |>>>>>  b) remap the parameter and raise the <NON QOSM HOP> flag 
> |>>>>>  defined in
> |>>>>>  Section 5.1, where the remapping MUST be specified in the QOSM
> |>>>>>  specification.  Here the terminology 'strictly 
> |>>>>>  interpret' means that
> |>>>>
> |>>>>What is the difference  between 'strictly interpret' and 
> |>>
> |>>'interpret'? 
> |>>
> |>>>>In the rest of the document you use 'interpret'.
> |>>>
> |>>>
> |>>>'Strictly interpret' is defined in the text I quoted from 
> |>>
> |>>Section 4.2 (QSPEC
> |>>
> |>>>Processing), which is given again in the very next 
> |>>
> |>>sentences I quoted just
> |>>
> |>>>below (after you posed your above question :-)
> |>>>
> |>>>"   Mandatory parameters provide a minimal subset of parameters. A
> |>>>   QNE MUST either a) strictly interpret a mandatory parameter, or
> |>>>   b) remap the parameter and raise the <NON QOSM HOP> flag 
> |>>
> |>>defined in
> |>>
> |>>>   Section 5.1, where the remapping MUST be specified in the QOSM
> |>>>   specification.  Here the terminology 'strictly 
> |>>
> |>>interpret' means that
> |>>
> |>>>   the parameter is implemented according to the commonly accepted
> |>>>   definition and/or as specified by references given for 
> each QSPEC
> |>>>   parameter.  This means that in case a), a <Token Bucket> 
> |>>
> |>>parameter
> |>>
> |>>>   must be strictly interpreted as a token bucket.  
> |>>
> |>>However, in case b),
> |>>
> |>>>   a <token Bucket> parameter may be remapped, perhaps to a 
> |>>
> |>><Bandwidth>
> |>>
> |>>>   parameter."
> |>>>
> |>>>In the document, the term 'interpret' a mandatory parameter 
> |>>
> |>>means either a)
> |>>
> |>>>strictly interpret (as defined above), or b) remap (as 
> |>>
> |>>defined above).
> |>>
> |>>>Perhaps this can be made clearer in the text.
> |>>> 
> |>>>
> |>>>
> |>>>>>  the parameter is implemented according to the 
> commonly accepted
> |>>>>>  definition and/or as specified by references given for 
> |>>
> |>>each QSPEC
> |>>
> |>>>>>  parameter.  This means that in case a), a <Token Bucket> 
> |>>>>>  parameter
> |>>>>>  must be strictly interpreted as a token bucket.  
> |>>>>>  However, in case b),
> |>>>>>  a <token Bucket> parameter may be remapped, perhaps to a 
> |>>>>>  <Bandwidth>
> |>>>>>  parameter.
> |>>>>
> |>>>>I noticed this text improvement and I am happy to see more 
> |>>
> |>>text about 
> |>>
> |>>>>it.
> |>>>>
> |>>>>Still, I have some issues with the section:
> |>>>>
> |>>>>I had a problem with this paragraph following the previous 
> |>>
> |>>one in the 
> |>>
> |>>>>section. The previous paragraph said "
> |>>>>However, if a QSPEC arrives at a QNE that does
> |>>>>   not support the QOSM being signaled, it can still 
> understand the
> |>>>>   QSPEC content, at least to a basic degree.
> |>>>>"
> |>>>>
> |>>>>When I read through the text I got the impression that the two 
> |>>>>sections relate to each other and in fact they do not. Hence, I 
> |>>>>suggest to delete the previous paragraph since this one 
> |>>
> |>>contains the 
> |>>
> |>>>>info already.
> |>>>
> |>>>
> |>>>I'm unclear as to which paragraph/text you are proposing 
> to delete.
> |>>>
> |>>>
> |>>>
> |>>>>You
> |>>>>might also want to delete the second paragraph as well 
> |>>
> |>>since it is far 
> |>>
> |>>>>too obvious to use RFC2119 language: If you don't support even a 
> |>>>>single QOSM then why are you a QOS NSLP node in the first place.
> |>>>
> |>>>
> |>>>I think it important to state that a QNE MUST support at 
> |>>
> |>>least one QOSM,
> |>>
> |>>>even if this is clearly necessary to effectively support 
> |>>
> |>>QoS-NSLP/QSPEC.
> |>>
> |>>>
> |>>>>You might want to highlight the following sentence, though:
> |>>>>
> |>>>>"
> |>>>>A QNE MUST interpret all mandatory parameters from this 
> |>>
> |>>document even 
> |>>
> |>>>>if it does not support the received QoS NSLP message with the 
> |>>>>indicated QOSM.
> |>>>>"
> |>>>>
> |>>>>Here is my proposal for the section:
> |>>>>
> |>>>>"
> |>>>>4.2 QSPEC Processing
> |>>>>
> |>>>>   The QSPEC is opaque to the QoS NSLP processing.  The 
> |>>
> |>>QSPEC control
> |>>
> |>>>>   information and the QoS description are interpreted and MAY be
> |>>>>   modified by the RMF in a QNE (see description in [QoS-SIG]).
> |>>>>
> |>>>>   The QSPEC contains a QOSM ID, i.e. information on what 
> |>>>>   QOSM is being
> |>>>>   signaled by the QNI.  However, if a QSPEC arrives at a 
> |>>>>   QNE that does
> |>>>>   not support the QOSM being signaled, it can still 
> understand the
> |>>>>   QSPEC content, at least to a basic degree.  This is 
> |>>>>   because mandatory
> |>>>>   parameters have been defined as a common language.  
> |>>>>   Therefore, a QNE
> |>>>>   MUST at least interpret all the mandatory parameters in a 
> |>>>>   QSPEC even
> |>>>>   if it does not support the corresponding QOSM.
> |>>>>
> |>>>>   A QNE MUST either
> |>>>>
> |>>>>   a) interpret a mandatory parameter carried in the QSPEC 
> |>>
> |>>object, or
> |>>
> |>>>>   b) remap the parameter and raise the <NON QOSM HOP> flag 
> |>>>>   defined in
> |>>>>   Section 5.1, where the remapping MUST be specified in the QOSM
> |>>>>   specification.
> |>>>>
> |>>>>   Here the terminology 'interpret' means that
> |>>>>   the parameter is implemented according to the references 
> |>>>>   given for 
> |>>>>   each QSPEC parameter.
> |>>>>
> |>>>>   If a QSPEC arrives at a QNE that does not support the 
> QOSM being
> |>>>>   signaled, it can still understand the QSPEC content, at 
> |>>
> |>>least to a
> |>>
> |>>>>   basic degree. Hence, with case (a), a <Token Bucket> parameter
> |>>>>   must be strictly interpreted as a token bucket.
> |>>>>
> |>>>>   In case b), a <token Bucket> parameter may be remapped, 
> |>>>>   perhaps to a
> |>>>>   <Bandwidth> parameter.
> |>>>>"
> |>>>
> |>>>
> |>>>I don't see any benefit in redefining what 'interpret' 
> means in the
> |>>>document.  As I mentioned above, the document uses the term 
> |>>
> |>>'interpret' to
> |>>
> |>>>mean that a mandatory parameter is 'interpreted' if is 
> |>>
> |>>either 'strictly
> |>>
> |>>>interpreted' or it is 'remapped' (where the remapping must 
> |>>
> |>>be defined in the
> |>>
> |>>>QOSM specification document).  OTOH, it might be useful 
> to define a
> |>>>'remapping' flag to indicated if a mandatory or optional 
> |>>
> |>>parameter has been
> |>>
> |>>>remapped by a QNE in the path.
> |>>> 
> |>>>
> |>>>
> |>>>>Btw, have you noticed that the draft has
> |>>>>* a <NON QOSM HOP> flag (Section 5.1)
> |>>>>* a <NON QOSM HOP> parameter (Section 7.2.1)
> |>>>>
> |>>>>I think they refer to the same concept...
> |>>>
> |>>>
> |>>>Yes, good catch.  <NON QOSM HOP> is indeed intended to be a 
> |>>
> |>>flag, and
> |>>
> |>>>perhaps one of the QSPEC object flags defined in Section 
> |>>
> |>>7.1 could be used
> |>>
> |>>>for this purpose, rather than use a full 32-bit parameter 
> |>>
> |>>for this purpose,
> |>>
> |>>>as currently specified in Section 7.2.1.
> |>>> 
> |>>>
> |>>>
> |>>>>>  In the latter case, the remapping of the <Token Bucket> to
> |>>>>>  <Bandwidth> must be specified in the QOSM specification 
> |>>
> |>>document.
> |>>
> |>>>>>  For example, QOSM X exclusively uses the parameter 
> |>>>>>  <Bandwidth>.  It
> |>>>>>  must define a mapping of the mandatory parameter 
> <Token Bucket>.
> |>>>>>  The mapping consists of interpreting the Token Bucket Rate as
> |>>>>>  the <Bandwidth> parameter and disregarding the other 
> |>>
> |>>Token Bucket
> |>>
> |>>>>>  parameters.  Clearly, some information contained in the <Token
> |>>>>>  Bucket> parameter is lost by this mapping, and the 
> |>>>>>  resulting QoS may
> |>>>>>  not be quite what was intended by the QNI.  Therefore, 
> |>>>>>  QOSM X also
> |>>>>>  specifies that the <NON QOSM HOP> flag be raised.  Thus, 
> |>>>>>  a QNE using
> |>>>>>  QOSM X is able to make an informed decision whether to admit a
> |>>>>>  reservation described in terms of <Token Bucket>, and 
> |>>
> |>>at the same
> |>>
> |>>>>>  time (by means of <NON QOSM HOP>) signals to the 
> |>>
> |>>QNI/QNR that the
> |>>
> |>>>>>  exact intention of the QNI may not be met."
> |>>>>>
> |>>>>>I think this text is pretty clear as to what is required 
> |regarding 
> |>>>>>interpreting mandatory parameters.  If not, please suggest 
> |>>>>>clarifications.
> |>>>>
> |>>>>The text in the new draft has improved a lot.
> |>>>>Thanks for the update.
> |>>>>
> |>>>>
> |>>>>
> |>>>>>>Another possible question would be:
> |>>>>>>"
> |>>>>>>Does a node that implements a particular QOSM has to 
> |>>
> |>>define mappings 
> |>>
> |>>>>>>from all mandatory parameters listed in the QSPEC 
> |>>
> |>>template draft to 
> |>>
> |>>>>>>the QOSM draft (even if the QOSM does not make use
> |>>>>
> |>>>>of them)?
> |>>>>
> |>>>>
> |>>>>>>"
> |>>>>>>
> |>>>>>>The answer is "I don't know".
> |>>>>>
> |>>>>>
> |>>>>>A QNE must interpret all mandatory parameters, if populated, as
> |>>>>>explained in the above text I quoted.  If a QOSM re-maps a 
> |>>
> |>>mandatory
> |>>
> |>>>>>QSPEC parameter, that re-mapping must be defined in the QOSM
> |>>>>>specification.  As stated in Section 4.7 (QOSM Specification
> |>>>>>Requirements):
> |>>>>>
> |>>>>>"   A QOSM specification MUST define QSPEC parameter 
> |>>>>>  behavior for these
> |>>>>>  cases: a) new optional QSPEC parameters the QOSM specification
> |>>>>>  defines, and b) remapping of existing mandatory or 
> |>>
> |>>optional QSPEC
> |>>
> |>>>>>  parameters, as described in Section 4.2.  Unless 
> |>>>>>  otherwise specified
> |>>>>>  in the QOSM specification document, the behaviors to strictly
> |>>>>>  interpret the mandatory and optional QSPEC parameters 
> |>>>>>  are defined in
> |>>>>>  this document through the references to RFCs that 
> |>>>>>  precisely define
> |>>>>>  the QSPEC parameter behaviors.  
> |>>>>>
> |>>>>>  A QOSM specification MUST define how the mandatory 
> |>>>>>  parameters are to
> |>>>>>  be mapped onto the QSPEC parameters used by the QOSM, 
> |>>
> |>>however the
> |>>
> |>>>>>  mapping MAY result in slight modification to the intended
> |>>>>>  specification when an exact mapping is not possible.  
> |>>>>>  This definition
> |>>>>>  MUST allow a QNE implementing this QOSM to make a 
> decision as to
> |>>>>>  whether a reservation described in terms of mandatory 
> |>>>>>  parameters can
> |>>>>>  be admitted.  If for a particular mandatory parameter no 
> |>>>>>  mapping can
> |>>>>>  be found that guarantees the desired QoS, the QNE is 
> |>>>>>  advised to raise
> |>>>>>  the <NON QOSM HOP> flag.  In other words, for all mandatory
> |>>>>>  parameters a mapping must be defined, but it is 
> |>>
> |>>acknowledged that
> |>>
> |>>>>>  this mapping may result in slightly bending the original 
> |>>>>>  intention of
> |>>>>>  the QNI."
> |>>>>>
> |>>>>>I think this text is pretty clear as to what is 
> required.  If not,
> |>>>>>please suggest clarifications.
> |>>>>
> |>>>>I understood the token bucket to bandwidth example.
> |>>>>
> |>>>>Would the RMD draft, for example, list all mandatory 
> |parameters and 
> |>>>>indicate whether it can map them (and how) to parameters used 
> |>>>>in the RMD 
> |>>>>specification?
> |>>>
> |>>>
> |>>>As stated in the QOSM specification requirements in Section 
> |>>
> |>>4.7, if a QOSM
> |>>
> |>>>remaps a mandatory parameter, the remapping must be defined 
> |>>
> |>>in the QOSM
> |>>
> |>>>specification document.  If no such remapping is defined, 
> |>>
> |>>the default
> |>>
> |>>>behavior is that the QOSM must strictly interpret the 
> |>>
> |>>mandatory parameter,
> |>>
> |>>>as defined above.
> |>>> 
> |>>>
> |>>>
> |>>>>Do you think it is awfully realistic for all QNEs to 
> |understand all 
> |>>>>mandatory parameters? I could imagine that Attila and 
> |>>>>Georgios are not 
> |>>>>going to implement stateless interior QNEs in such a way 
> that they 
> |>>>>understand all the mandatory QSPEC parameters. In fact they 
> |>>>>don't have 
> |>>>>todo it since only edge routers are likely to ever see QoS 
> |>>>>NSLP messages 
> |>>>>that contain QOSM IDs that they do not understand (otherwise 
> |>>>>something 
> |>>>>go terribly wrong).
> |>>>
> |>>>
> |>>>It is up the RMD authors to specify how they want RMD to 
> behave wrt
> |>>>mandatory parameters (and obtain rough consensus, of 
> |>>
> |>>course).  That is, if a
> |>>
> |>>>mandatory parameter is remapped and not strictly 
> |>>
> |>>interpreted, the remapping
> |>>
> |>>>must be specified in the QOSM specification document.  
> |>>
> |>>Otherwise, the QOSM
> |>>
> |>>>must strictly interpret the mandatory parameters that are 
> |>>
> |>>not remapped, if
> |>>
> |>>>they are populated by the QNI.
> |>>>
> |>>>There are no restrictions on how the remapping must be 
> |>>
> |>>done, it can be as
> |>>
> |>>>simple as necessary (but no simpler).
> |>>>
> |>>>Thanks,
> |>>>Jerry
> |>>>
> |>>>
> |>>>
> |>>>>Ciao
> |>>>>Hannes
> |>>>>
> |>>>>
> |>>>>
> |>>>>>Thanks,
> |>>>>>Jerry
> |>>>>>
> |>>>>>
> |>>>>>
> |>>>>>
> |>>>>>>Ciao
> |>>>>>>Hannes
> |>>>>>>
> |>>>>>>The QSPEC-draft says in section 5
> |>>>>>>
> |>>>>>>
> |>>>>>>
> |>>>>>>>that
> |>>>>>>>all parameters listed in the next sections are mandatory. The 
> |>>>>>>>QSPEC-draft also
> |>>>>>>>says in section 4.1 that "a given QOSM defines which of the 
> |>>>>>>
> |>>>>>>mandatory and
> |>>>>>>
> |>>>>>>
> |>>>>>>
> |>>>>>>>optional parameters it uses, ..."
> |>>>>>>>
> |>>>>>>>Are there any specific parameters which makes the open 
> |>>>>
> |>>>>issue B.1.1. 
> |>>>>
> |>>>>
> |>>>>>>>clearer? Following the QSPEC-draft there doesn't seem to be 
> |>>>>>>
> |>>>>>>a conflict, 
> |>>>>>>
> |>>>>>>
> |>>>>>>
> |>>>>>>>if nothing is
> |>>>>>>>done with the unneeded parameters.
> |>>>>>>>
> |>>>>>>>Thanks,
> |>>>>>>>Bernd
> |>>>
> |>>>
> |>>>_______________________________________________
> |>>>nsis mailing list
> |>>>[email-masked]
> |>>>https://www1.ietf.org/mailman/listinfo/nsis
> |>>>
> |>>>
> |>>>
> |>>
> |>>
> |> 
> |> _______________________________________________
> |> nsis mailing list
> |> [email-masked]
> |> https://www1.ietf.org/mailman/listinfo/nsis
> |> 
> |
> |
> |_______________________________________________
> |nsis mailing list
> [email-masked]
> |https://www1.ietf.org/mailman/listinfo/nsis
> |
> 

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