Re: [NSIS] QSPEC document

[Lars Westberg <Lars.westberg at ericsson.com>]

sure, extendabillity is  the key thing.
Thats why I have problems with statement into a new protocol without any deployment and experience of commercial acceptance. Especially if the statement is unclear.

from my view, the QoS-model template should be a template and each QoS-model should be registered by IANA. I think that's according to the normal rule.



regards Lasse

john.loughney at nokia.com wrote:

Hi Lars,

All Standards Track documents are required to have an IANA Considerations section, which describes how protocols can be extended.

You might be familiar with RFC 3936 "Procedures for Modifying the Resource reSerVation Protocol"

The IETF has certain rules with respect to protocol extensibility.
You cand find some of them in (for example)  RFC3692 & RFC2434.


John


________________________________

        From: ext Lars Westberg [mailto:Lars.westberg at ericsson.com]
        Sent: 23 January, 2007 09:01
        To: Loughney John (Nokia-NRC/PaloAlto)
        Cc: "Attila Báder (IJ/ETH)"; gash at att.com; nsis at ietf.org
        Subject: Re: [NSIS] QSPEC document
       
       
        comments inline
       
        john.loughney at nokia.com wrote:
       

                Hi Attila,
               
                >Hi John and Jerry, I think there is a misundersatnading here.
                >The QoS NSLP functionality surely cannot be changed without
                >modifying QoS NSLP.
               
                I think we agree here.  I think we are trying to discuss
                how much change is possible.
               

        why are we discussing it ??
       
        If we need to add a new function in the future ?
        should we have statement into the protocol spec how this should be solved without knowing about the problem to solve?
       
        I have never seen any statements within RFCs how extention of future protocol problems should be solved. So what are we discussion ????
       

               
                >Regarding the QoS-NSLP state machine, I think it is not
                >definitive and it is determined by QoS NSLP and QOSM together.
                >The RMF functions are clearly determined the QOSM. It does not
                >mean to define new QoS NSLP signaling functionality.
               
                I agree.


        First of all, does internal desing model determine the protocol operation?
        According to my understanding, the standard only covers the protocol operation between routers, not how they are implemented.
       
        I do not know but I thought that API:s does not make sense as a restriction and internal implementation model is only as an information and does not determine a standard track.
       
        I would appreciate to more clarification of this.
       

               
               
                John
               
                _______________________________________________
                nsis mailing list
                nsis at ietf.org
                https://www1.ietf.org/mailman/listinfo/nsis
               

_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis