|
Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard
2009-07-21 17:40:26
Hi Tom,
> 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?
I don't see a good solution to this. I think the text should be
strengthened; at
present, it seems a little casual, not quite serious enough. The
referenced I-D
is massive, contains much that I suspect will not be relevant to MPLS-TP
and
seems an unsatisfactory companion to this I-D. I think that
draft-mpls-tp-oam-requirements does a much better job here, and would like
to
see something similar, highlighting the key threats (and for MPLS-TP, I do
not
know what they are:-(
As luck would have it, a couple of people have just posted
draft-fang-mpls-tp-security-framework-00.txt
This is in early days, but I think that draft-ietf-mpls-tp-requirements
should be able to defer to it for security in the same non-normative way
that it defers to draft-mpls-tp-oam-requirements for OAM and
draft-mpls-tp-nm-requirements for network management.
Cheers,
Adrian
> 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?
That sounds like a viable solution. My sense is that because this has
come
first, or at least early on, it has accumulated definitions it does not
need.
Technically, I fear we will regret not producing the Rosetta Stone first,
but
politically, I suspect that that is unrealistic and so we have to do as
you
suggest.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|