----- Original Message -----
From: "Adrian Farrel" <adrian(_at_)olddog(_dot_)co(_dot_)uk>
To: "Tom.Petch" <sisyphus(_at_)dial(_dot_)pipex(_dot_)com>
Cc: "ietf" <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, July 21, 2009 11:36 PM
Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP
Requirements)toProposed Standard
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.
OK
Tom Petch
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