AD review: draft-ietf-nsis-nslp-auth-02.txt

Summary: Not ready, revision needed, see below.

Meta question: This document is very complex. Do we have any real experience with coupling NSLP authorization with X.500, Kerberos, PGP, etc.? Do any of the experimental implementations use this to authorize QoS NSLP or NATFW NSLP actions?



Section 1., paragraph 2:
>    Currently, this node would run either the QoS or
>    the NAT/FW NSLP service.

  Cite the two NSLP documents.


Section 2., paragraph 1:
>    The NSIS working group is specifying a suite of protocols for the
>    next generation in Internet signaling [RFC4080].

  Rephrase to omit mentioning the NSIS WG before publication as an RFC.


Section 2., paragraph 3:
>    The so far specified basic security architecture for NSIS is based on

  s/so far specified//   (there won't be any other, no?)


Section 3.1., paragraph 8:
>    flag cominbation is not used by all NSLPs, e.g., it is not used in

  Nit: s/cominbation/combination/


Section 3.2., paragraph 5:
>       Session authorization attribute type (X-Type) field is one octet.
>       IANA acts as a registry for X-Types as described in Section 7,
>       IANA Considerations.  Initially, the registry contains the
>       following X-Types:

  The IANA considerations are in Section 8. And that section doesn't
  define this new registry.


Section 3.2.1., paragraph 6:
>       The following sub-types for AUTH_ENT_ID are defined.  IANA acts as
>       a registry for AUTH_ENT_ID sub-types as described in Section 7,
>       IANA Considerations.  Initially, the registry contains the
>       following sub-types of AUTH_ENT_ID:

  The IANA considerations are in Section 8. And that section doesn't
  define this new registry.


Section 3.2.2., paragraph 6:
>       The following sub types for SOURCE_ADDR are defined.  IANA acts as
>       a registry for SOURCE_ADDR sub-types as described in Section 7,
>       IANA Considerations.  Initially, the registry contains the
>       following sub types for SOURCE_ADDR:

  The IANA considerations are in Section 8. And that section doesn't
  define this new registry.


Section 3.2.3., paragraph 3:
>    Length: Length of the attribute in number of octects, which MUST be >

  Nit: s/octects,/octets,/


Section 1., paragraph 0:
>    1.  1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.

  RFC1305 needs to be a normative reference.


Section 3.2.6., paragraph 2:
>    The creator of the this attribute lists every NSLP object type whose

  Nit: Maybe you need to remove the second determiner so that only 'the'
  or 'this' is left.


Section 3.2.6., paragraph 6:
>    | No of signed NSLP objects = n |  rsv  |  NSLP object type (1) |

  Nit: s/No/Nr./ (also elsewhere)


Section 3.2.6., paragraph 10:
>    SubType: No sub types for NSLP_OBJECT_LIST are currently defined.
>    This field MUST be set to 0.

  And ignored upon reception.


Section 3.2.6., paragraph 13:
>    rsv: reserved bits and must be set to 0 (zero).

  And ignored upon reception.


Section 3.2.6., paragraph 15:
>    padding: padding is required if the number of NSLP objects is even.
>    The padding field MUST be 16 bit set to 0.

  Ambiguous. You mean that the padding is REQUIRED when even and that it
  MUST NOT be added when odd.


Section 4.2., paragraph 3:
>    Another opton is to encapsulate the credentials in the AUTH_DATA

  Nit: s/opton/option/


Section 4.3.1.1., paragraph 5:
>    o  Certification Path Validation is performed as defined in Section 6
>       of RFC 3280.

  RFC3280 needs to be cited.


Section 4.3.1.2., paragraph 2:
>    o  AUTHENTICATION_DATA contains a Signature Packet as defined in
>       Section 5.2.3 of RFC 2440.  In summary:

  RFC2440 needs to be cited.


Section 6.2., paragraph 0:
> 6.2.  Processing within the QoS NSLP

  Does this mean that this document updates draft-ietf-nsis-qos-nslp?


Section 2., paragraph 0:
>        must contruct and send a RESPONSE message with the status of

  Nit: s/contruct/construct/


Section 6.3., paragraph 0:
> 6.3.  Processing with the NAT/FW NSLP

  Does this mean that this document updates draft-ietf-nsis-nslp-natfw?


Section 7., paragraph 2:
>    different network entities may not be in synch.  The start time is

  Nit: s/synch./sync./


Section 10.2., paragraph 4:
>    [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>               Resource Identifiers (URI): Generic Syntax", RFC 2396,
>               August 1998.

  Obsolete informational reference (is this intentional?): RFC 2396
  (Obsoleted by RFC 3986)


Section 10.2., paragraph 7:
>    [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
>               RFC 3852, July 2004.

  Obsolete informational reference (is this intentional?): RFC 3852
  (Obsoleted by RFC 5652)

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis