Hello authors and WG chairs,
On my review comments from Nov-10, 2007, I did not receive answers to my
comments from you, yet.
As this draft is planned to be discussed on the IESG telechat, could you
please clarify how you intend to answer to these things (correct, reject
or whether we shall raise a ?DISCUSS? during the LC to halt the document
process until the issues have been resolved).
Best regards, Tobias
Ps.: Please note: my main email address changed to:
tobias(_dot_)gondrom(_at_)gondrom(_dot_)org
_____________________________________________
From: Tobias Gondrom
Sent: Saturday, November 10, 2007 12:02 AM
To: secdir(_at_)mit(_dot_)edu; iesg(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; 'mohand(_at_)nortel(_dot_)com';
'sajassi(_at_)cisco(_dot_)com';
'sdelord(_at_)uecomm(_dot_)com(_dot_)au';
'philippe(_dot_)niger(_at_)francetelecom(_dot_)com'
Subject: [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-09
Hello,
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments
just like any other last call comments.
I studied the draft and a have the following COMMENTS and leave it at the
discretion of the ADs whether they want to raise any DISCUSS based on
these COMMENTS:
1. a few editorial:
Section 1:
s/relationship between two layered networks; Fault Detection at the
server/ relationship between two layered networks, Fault Detection at the
server
s/associated Pseudowires (PWs)/ associated Pseudo Wires (PWs)
unclear statements:
Section 1:
I found the following sentence imprecise and hard to understand:
?Performance Management deals with mechanism(s) that allow
determining and measuring the performance of network/services under
consideration and notification of them.?
Section 1.1: I would suggest to add CE and PE to the terminology of this
document. It can only be derived from following a two-step indirect
reference (via RFC4664 and then the reference mentioned there, which is
stated as ?work in progress?). For improved convenience the terminology
should be referred directly from the document, or even better and more
simple just add those two (CE and PE) to its Terminology.
2. the document does not state its intended status: based on its content
and its relationship to the two other referred RFCs 4664 and 4665, I would
assume it is Informational.
If this assumption is wrong, the intended status should be clarified ASAP.
3. The document does not seem to use RFC-2119 coherently. Throughout the
document there are numerous places where I do not understand why authors
use ?must? instead of ?MUST?. One example:
Section 6.10:
Security implies that an OAM domain must be capable of filtering OAM frames.
=> should be: ?Security implies that an OAM domain MUST be capable of
filtering OAM frames.?
And:
?Also, OAM frames from outside the OAM domains should be either discarded
(when such OAM frames belong to same or lower-level OAM domain) or
transparently passed (when such OAM frames belong to a higher-level OAM
domain).?
=> Should be at least:
?Also, OAM frames from outside the OAM domains SHOULD be either discarded
(when such OAM frames belong to same or lower-level OAM domain) or
transparently passed (when such OAM frames belong to a higher-level OAM
domain).?
In the context of the sentence I even wonder if ?MUST? isn?t more precise,
as it MUST either be the first or the second.
Equivalent in Section 7.10.:
?Security implies that an OAM domain must be capable of filtering OAM
frames.?
=> should become: ??Security implies that an OAM domain MUST be capable of
filtering OAM frames.?
And: ?Also,VPWS OAM frames from outside the OAM domains should be either
discarded?
=> should become: ?Also,VPWS OAM frames from outside the OAM domains MUST
be either discarded?
Please note, my personal opinion is that RFC-2119-language usage seems
incoherently throughout large parts of the document and not only in these
two sections. But maybe my personal expectation is not correct for an
Informational Draft in the context of this area.
4. The security Considerations (section 11) states that it does not need
further security considerations as it only imposes requirements to
solutions but does not describe the solutions themselves. In fact I
believe this statement to be wrong in even two ways:
1. the initial abstract declares this draft is about the requirements AND
a framework
2. even if the document would only be talking about requirements (and not
about any implications on a framework), it should still clearly include
security considerations for the requirements as they are already partially
done in section 6.10 and section 7.10.
Last but not least, if the authors would still like to keep this section
(11) as it is ? which I would not recommend - they should consider to
correct the following spelling errors:
s/ For additional levels of security, the solutions may be required deploy
to encrypt and/or authenticate OAM frames inside an OAM domain however
solutions are out of the scope of this draft./For additional levels of
security, the solutions may be required to deploy encryption and/or
authentication of OAM frames inside an OAM domain, however solutions are
out of the scope of this draft.
5. Question: as the draft is heavily based on RFC4664 and 4665, I wonder
whether they should not better be normative references instead of
informative ones?
Best regards, Tobias
__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security
Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn
Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias(_dot_)gondrom(_at_)opentext(_dot_)com
Internet: http://www.opentext.com/
Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH,
Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89
4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht:
München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number
/USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John
Shackleton, Walter Köhler
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf