Thanks for the input Tom,
I see some difficulties with the references in this I-D.
a) The security section of this I-D says
see [I-D.ietf-mpls-mpls-and-gmpls-security-framework]
which is an informative reference.
I believe that security should be normative, not informative, even in
this, a
requirements (as opposed to a protocol) draft.
I hear you. Security is fundamental.
draft-ietf-mpls-mpls-and-gmpls-security-framework is targetted as an
informational RFC because it does not define any protocol mechanisms. It is
a catalog of existing protocol security mechanisms and reports the current
state of the art.
In the light of this, do you believe it is necessary to create a downref
from a requirements document to an informational document?
Could this be handled by strenghtening the text in the security requirements
section?
b) The terminology section of this draft overlaps with that in an
Informational
Reference [I-D.helvoort-mpls-tp-rosetta-stone] "A Thesaurus for the
Terminology
used in MPLS-TP drafts/RFCs and ITU-T's Transport Network
Recommendations."
(now republished as a Working Group Draft)
which will doubtless progress to an RFC but as Informational. I see this
as
problematic; the two may be in step now but I am doubtful that they will
be as
and when this last gets amended in the course of its development. The
mpls-tp
list has seen some vigorous debate already about the meaning of terms (eg
associated bidirectional, AIS). Sometimes, the same concept has a
different
term in IETF versus ITU-T (versus IEEE) while the same term may also be
used for
a different concept.
RFC4397 is the product of a similar, earlier issue and is another
potential
overlap.
The definitions in this I-D may be normative for this I-D but if they
diverge from definitions in other I-Ds, we are storing up problems for the
future.
On balance, I believe that this rosetta-stone should be a Normative
Reference,
ideally removing the overlapping definitions.
You are right, of course, that terminology needs to be consistent. But
making a normative reference to the Rosetta Stone draft would put us into a
nasty non-publication loop because that draft can't be published until
everything else is completely stable, and nothing else can be published with
a normative reference to an unpublished I-D.
Would it work for the authors to take a long hard look at the terms they
have to:
1. make sure they only define terms they really need and cannot defer
to the Rosetta Stone
2. ensure the Rosetta Stone is up-to-date and includes pointers out to
the initial definitions so that the terms do not get updated in the
future?
Cheers,
Adrian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf