----- Original Message ----- From: "Adrian Farrel" <adrian@xxxxxxxxxxxx> To: "Tom.Petch" <sisyphus@xxxxxxxxxxxxxx> Cc: "ietf" <ietf@xxxxxxxx> Sent: Monday, July 20, 2009 5:47 PM Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard > 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? 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:-( > > 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. Tom Petch > Cheers, > Adrian _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf