----- Original Message ----- From: "Adrian Farrel" <adrian@xxxxxxxxxxxx> To: "Tom.Petch" <sisyphus@xxxxxxxxxxxxxx> Cc: "ietf" <ietf@xxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf