Subject: Re: [NSIS] WGLC on draft-ietf-nsis-nslp-auth-02.txt

From: Roland Bless <[email-masked]>
Date: Fri, 09 Jul 2010 12:49:06 +0200

Hi Xiaoming,

Am 22.06.2010 13:21, schrieb Xiaoming Fu:
> Reads good to me. One comment:
> 
>    AB=00 ("Mandatory"): If the object is not understood, the entire
>    message containing it MUST be rejected, and an error message sent
>    back (usually of class/code "Protocol Error/Unknown object present").
> 
> "Protocol Error/Unknown object present" --> "Protocol Error/Object Type
> Error (subcode Unrecognised Object)"?

The latest qos nslp draft says:

   * 0x07 - Unknown object present: an object of an unknown type was
   present in the message.

The latest natfw draft says:
   o  AB=00 ("Mandatory"): If the object is not understood, the entire
      message containing it MUST be rejected with an error RESPONSE of
      class 'Protocol error' (0x3) with response code 'Unknown object
      present' (0x06).

So why do you think that this must be changed?

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Fri, 09 Jul 2010 12:56:59 +0200

Hi Lars,

Am 17.06.2010 05:35, schrieb Lars Eggert:

> OK. So there is no interoperability issue between nodes that implement nslp-auth and ones that do not.

No, there is no issue as the extensibility flags must be set to
10 = forward, a non-session auth aware node will ignore the object and
pass it on. Nodes that implement it, care whether the
object is present or not, e.g., thereby enforcing necessary security.

Regards,
 Roland

---

From: Lars Eggert <[email-masked]>
Date: Thu, 29 Jul 2010 13:56:18 +0200

Hi,

I re-reviewed -05. There are remaining issues that need to be fixed:

>    X-Type: 8 bits
> 
>       Session authorization attribute type (X-Type) field is one octet.
>       IANA acts as a registry for X-Types as described in Section 8,
>       IANA Considerations.  This specification uses the following
>       X-Types:

Section 8 does not define a registry for X-Types.

> SubType:
> 
>       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 8,
>       IANA Considerations.  Initially, the registry contains the
>       following sub-types of AUTH_ENT_ID:

Section 8 does not define a registry for these sub-types.

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

Section 8 does not define a registry for these sub-types.

> SubType:
> 
>       The following sub types for DEST_ADDR are defined.  IANA acts as a
>       registry for DEST_ADDR sub-types as described in Section 8, IANA
>       Considerations.  Initially, the registry contains the following
>       sub types for DEST_ADDR:

Section 8 does not define a registry for these sub-types.

> 1.  1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 5905
>        [RFC5905].

RFC5905 needs to be a normative reference.

Lars