Dear Alissa,
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. In particular,
(1) I think there are some errors in Table 1, or perhaps there are just
formatting issues that have me confused.
It looks like TCP, SCTP, DCCP, UDP, and HTTP are listed under Layer 3.
<jcs>
FIXED
</jcs>
I can't tell if there is meant to be a
difference between header fields separated by slashes versus those
separated on
different lines.
<jcs>
There isn't, not sure how that got there. FIXED
</jcs>
There seems to be an extra column in front of the HTTP fields
-- what does that signify?
<jcs>
It signifies a formatting error. :-) FIXED
</jcs>
Why is TRAM profile in particular included as an
example here?
<jcs>
TRAM included work on authentication and authorization problems for TURN
and STUN in particular. That being said, I have no objection to removing
this row in the table; please advise.
</jcs>
(2) Tables 2-4 also seem to be specified in a significant amount of detail,
given that context and actions themselves are defined in detail in a
different
individual draft. This makes it hard to understand the implications of some
of
the fields. E.g., the "GPS coords" field -- whose GPS coords does this refer
to? It seems like the fields in these tables either need to be explained
more,
or they should be removed.
<jcs>
The following note was added:
Note: These fields are used to provide context information for I2NSF
Policy Rules to make decisions on how to handle traffic. For
example, GPS coordinates define the location of the traffic that
is entering and exiting an I2NSF system; this enables the
developer to apply different rules for ingress and egress
traffic handling.
</jcs>
(3) I'm not going to stand in the way of publication but it's not clear to
me
why this document needs to be an RFC. Much of the content seems like a
generic
narrative that describes how NSFs could work but doesn't really lay out any
concrete constraints about how they should work that would lead to greater
interoperability.
<jcs>
It is meant to be a reference model, not a BCP or implementation guidelines.
That being said, we would welcome suggestions to provide additional
clarifying text.
</jcs>
best regards,
John
On Wed, Oct 25, 2017 at 1:48 PM, Alissa Cooper <ali...@cooperw.in> wrote:
> Alissa Cooper 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:
> ----------------------------------------------------------------------
>
> (1) I think there are some errors in Table 1, or perhaps there are just
> formatting issues that have me confused. It looks like TCP, SCTP, DCCP,
> UDP,
> and HTTP are listed under Layer 3. I can't tell if there is meant to be a
> difference between header fields separated by slashes versus those
> separated on
> different lines. There seems to be an extra column in front of the HTTP
> fields
> -- what does that signify? Why is TRAM profile in particular included as an
> example here?
>
> (2) Tables 2-4 also seem to be specified in a significant amount of detail,
> given that context and actions themselves are defined in detail in a
> different
> individual draft. This makes it hard to understand the implications of
> some of
> the fields. E.g., the "GPS coords" field -- whose GPS coords does this
> refer
> to? It seems like the fields in these tables either need to be explained
> more,
> or they should be removed.
>
> (3) I'm not going to stand in the way of publication but it's not clear to
> me
> why this document needs to be an RFC. Much of the content seems like a
> generic
> narrative that describes how NSFs could work but doesn't really lay out any
> concrete constraints about how they should work that would lead to greater
> interoperability.
>
>
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
--
regards,
John
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
