|
Hi Lars,
I think we are
approaching agreement on this issue, so I'll give people a chance to comment and
then see if we can get text.
I have been concerned about different QoS Models
introducing too many changes to the basic operation that it becomes hard to
deploy end-to-end, or that implementations would have to be customized quite
heavily for each QoS Model.
But I think we are getting close to resolving
this.
thanks,
John
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
|