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 aninformational RFC because it does not define any protocol mechanisms. It is a catalog of existing protocol security mechanisms and reports the currentstate 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 requirementssection?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 andseems an unsatisfactory companion to this I-D. I think thatdraft-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 notknow 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. Butmaking a normative reference to the Rosetta Stone draft would put us into anasty non-publication loop because that draft can't be published untileverything else is completely stable, and nothing else can be published witha 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 yousuggest.
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf