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

Lars Eggert <[email protected]> Thu, 17 Jun 2010 11:35:44 +0800
Newsgroups gmane.ietf.nsis
Message-ID <[email protected]>
Hi,

On 2010-6-11, at 22:09, Roland Bless wrote:
> on 11.06.2010 15:15, Lars Eggert wrote:
>> Summary: Not ready, revision needed, see below.
>> 
>> Meta question: This document is very complex. Do we have any real
> 
> I guess that this problem is caused by the fact that
> the document heavily bases on the
> Session Authorization Policy Element for RSVP (RFC 3520).
> 
>> experience with coupling NSLP authorization with X.500, Kerberos,
>> PGP, etc.? Do any of the experimental implementations use this to
> 
> So the question is: is RFC 3520 really used anywhere in existing
> RSVP deployments? If not, probably we can dismiss most of the
> RFC 3520 legacy stuff and aim for something simpler (that
> is actually my preference), since there is no reason for code
> reuse.

AFAIK RFC3520 is not widely used. But it's too late for major changes like this. If we're unsure about how the authorization function should look like, we can punt on the work item, now that NSIS is only going for Experimental.

>> Section 6.2., paragraph 0:
>>> 6.2.  Processing within the QoS NSLP 
> 
>> Does this mean that this document updates draft-ietf-nsis-qos-nslp?
> 
> Good question. I don't think so, since you perform additional
> actions when implementing  draft-ietf-nsis-nslp-auth, so it
> affects the implementation behavior, but not the basic
> QoS NSLP protocol behavior.

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

Lars

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis
smime.p7s (application/pkcs7-signature, 3.7 KB) - not displayed