Dear Ben,
thank you for performing this review. All of your issues will be addressed
in version 9 of this I-D, to be released on Monday 11/13.
Please note that I will change RFC2119 boilerplate to RFC8174
boilerplate. Specifically:
old text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
Note: as this is an informational document, no RFC-2119 key words
are used.
new text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Note: as this is an informational document, no normative [RFC2119]
[RFC8174] key words are used.
Dear Kathleen,
thank you for providing clarification and direction for addressing Ben's
comments. In particular,
the old bullet was:
o Closed environments, where there is only one administrative
domain. Less restrictive access control and simpler validation
can be used inside the domain because of the protected nature of
a closed environment.
the new bullet will be
o Closed environments, where there is only one administrative
domain. Such environments provide a more **isolated**
environment, but still communicate over the same set of I2NSF
interfaces present in open environments (see above). Hence, the
security control and access requirements for closed environments
are the same as those for open environments.
regards,
John
On Tue, Oct 24, 2017 at 8:18 PM, Kathleen Moriarty <
[email protected]> wrote:
>
>
> Sent from my iPhone
>
> > On Oct 24, 2017, at 11:08 PM, Ben Campbell <[email protected]> wrote:
> >
> > Ben Campbell has entered the following ballot position for
> > draft-ietf-i2nsf-framework-08: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > -2: If no 2119 keywords are used, please remove the boilerplate. But if
> you do
> > need to keep it, please use the updated boilerplate from 8174, since
> there are
> > a number of lower case versions of 2119 keywords.
> >
>
> Thanks, I have been catching this, but must have missed it in this draft.
>
> > -6.2: first bullet: I am always worried about text advising that "closed
> > environments" have lower security requirements. That has proven false so
> many
> > times we really shouldn't be encouraging it. This is especially
> worrisome since
> > the first paragraph of section 11 talks about the importance of
> "trustworthy,
> > robust, and fully secured access".
>
> Yes, good catch. Was 'isolated' the intent here? If so, that's fine to
> assume a higher level of trust, but unlikely to be using I2NSF.
>
> Thanks,
> Kathleen
> >
> >
> > _______________________________________________
> > I2nsf mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/i2nsf
>
> _______________________________________________
> I2nsf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
--
regards,
John
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
