Hi Dimitri,
In producing the new revision of the WG doc I have made some changes to
address your points as follows...
a couple of comments though
-- concerns on section 3.3 - it will for each document open the pandora
box of the protocol dependencies - these should remain at most
illustrative otherwise
o) becoming restrictive with respect to the protocol applicability -
o) potentially impacting and/or assuming other protocol(s) behaviour
Quite right.
In fact, the intention is to uncover any issues that might prevent future
applicability and to unearth any issues that might cause disruptive impacts
on other protocols.
In section 3.3 (Liveness Detection and Monitoring) I have added some words
to help guide what should be discussed.
In section 3.5 (Requirements on Other Protocols and Functional Components)
which is also relevant here, I have added a caveat to say that the author is
not expected to describe the interaction with every protocol, but should
describe the interactions that are assumed in order to achieve correct
functioning of the new protocol.
Lastly, in section 3.6 (Impact on Network Operation) I have clarified the
need for examination of backward compatibility from the perspective of
network management.
-- generally speaking, the document should state that manageability
description shall ideally remain device/implementation independent (of
course there will be always exceptions)
This is a good point that David Harrington has captured in his I-D. I have
added some text to the introduction sections.
-- the document says "3.1 Control of Function and Policy
This sub-section describes the configurable items that exist for the
control of function or policy"
the control of functions - via the protocol elements described in the
document is important - but the term policy is to vague at which level of
the policy specification does that section applies
Hmmm. I think that I actually meant "Control of Function through
Configuration and Policy"
That is, I meant that the document should identify which protocol features
are controllable through policy. I did not mean that the authors should have
to describe in this section how the policy is controlled (since there are
frameworks and architectures to discuss that in general terms).
I have updated this section accordingly.
-- the document on network operations is important as it forces the writer
to document the dimensions impacting the protocol deployment nevertheless
assuming this is the case (taking the example of the doc. the implementer
is aware of the scaling threat) which mechanism are in place to prevent
protocol deployment ? i guess this boils down somehow to the RFC 1264
discussion and ultimately to the usefulness of the doc. not in terms of
description but actual practice
Thanks for reminding me about RFC 1264 and the discussion that led to it
being obsoleted. Yes, in time, this I-D may also be found to be overly
oppressive, inflexible, or out of date. Experience will show. At the moment,
however, the trend has been to ignore manageability and we are trying this
experiment to see if we can get things back on track.
By the way, I think section 3.6 (Impact on Network Operation) would benefit
from some additional work and I would appreciate textual suggestions.
Thanks,
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
