Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 14 Oct 2014 08:03:02 +0200

Hi Bill,

are you proposing to write a new "generic client" I-D/RFC in the OAuth WG?

kind regards, 
Torsten. 

<div>-------- Ursprüngliche Nachricht --------</div><div>Von: Bill Mills <[email-masked]> </div><div>Datum:13.10.2014  23:05  (GMT+01:00) </div><div>An: Torsten Lodderstedt <[email-masked]>, [email-masked] </div><div>Cc: [email-masked], Hannes Tschofenig <[email-masked]>, Benjamin Kaduk <[email-masked]> </div><div>Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt </div><div>
</div>3 through 6 should be handled by OAuth (and OpenID?) and are outside the scope of this spec.  This spec deals with 1 and maybe 2 & 7 above).  

A generic mail/contacts/calendar client will used more than SASL endpoints, notably CalDAV and CardDAV.  This isn't the place to solve the general problem.   

-bill

On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt <[email-masked]> wrote:

Hi Bill,

Am 13.10.2014 18:08, schrieb Bill Mills:
I totally agree that generic and interoperable OAuth client implementations need both endpoint discovery and client registration.  I disagree that this spec needs registration.  
This spec is about using OAuth on resource servers which have nothing to do with authentication and token issuance.

I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach? 

I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth.
Such a generic client must (at most) perform the following steps in order to get access to the resource server:

1) client tries to access resource server
2) resource server refuses access and returns discovery URL
3) client obtains metadata from discovery URL
4) client determines its client credentials for this particular authz server
5) if client is not in possession of suitable client credentials ->  register with the authz server (at the registration endpoint obtained from the discovery document)
6) client performs authz flow with the authz server
7) client accesses resource server again (with new access token) 

This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process. 

Do you have an alternative proposal to achieve this goal? 

We might need to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.

There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments). 

kind regards,
Torsten.

On whether to specify the full OpenID Connect Discovery schema, I think a SHOULD is reasonable, I don't really like the MUST.

On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt <[email-masked]> wrote:

Hi all,

as one of the proposers (beside Hannes) of the change, I would like to explain the rationale.

> -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.

Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a look at                 https://bugzilla.mozilla.org/show_bug.cgi?id=849540.

Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
  
In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and                 therefore are a significant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process. So the                 authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user
passwords on devices.
  
So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate                 (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall process.

That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well.

Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
Beside that it is already implement in existing OpenId                 Connect deployments.

> #2)  I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.

Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.

>  New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST                 always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill

---

From: Bill Mills <[email-masked]>
Date: Tue, 14 Oct 2014 15:06:55 +0000 (UTC)

I wasn't planning to.   OpenID is already doing it basically.  There might not yet be  a "here's what a well behaved generic client looks like" draft yet, but is that really needed? 

     On Monday, October 13, 2014 11:03 PM, Torsten Lodderstedt <[email-masked]> wrote:

 Hi Bill,
kind regards, Torsten. 

-------- Ursprüngliche Nachricht --------Von: Bill Mills Datum:13.10.2014 23:05 (GMT+01:00) An: Torsten Lodderstedt , [email-masked] Cc: [email-masked], Hannes Tschofenig , Benjamin Kaduk Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt 
3 through 6 should be handled by OAuth (and OpenID?) and are outside the scope of this spec.  This spec deals with 1 and maybe 2 & 7 above).  
A generic mail/contacts/calendar client will used more than SASL endpoints, notably CalDAV and CardDAV.  This isn't the place to solve the general problem.   

-bill

  Hi Bill,

 

 

 
 
 kind regards,
 Torsten.

 

 Hi all,

 

   

   

 

 

 

 
 kind regards,
 Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 15 Oct 2014 20:06:56 +0200

Am 14.10.2014 17:06, schrieb Bill Mills:
> I wasn't planning to.   OpenID is already doing it basically.  There 
> might not yet be  a "here's what a well behaved generic client looks 
> like" draft yet, but is that really needed?

I think so.

> -------- Ursprüngliche Nachricht --------
> Von: Bill Mills
> Datum:13.10.2014 23:05 (GMT+01:00)
> An: Torsten Lodderstedt , [email-masked]
> Cc: [email-masked], Hannes Tschofenig , Benjamin Kaduk
> Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
>
> 3 through 6 should be handled by OAuth (and OpenID?) and are outside 
> the scope of this spec. This spec deals with 1 and maybe 2 & 7 above).
>
> A generic mail/contacts/calendar client will used more than SASL 
> endpoints, notably CalDAV and CardDAV.  This isn't the place to solve 
> the general problem.
>
> -bill
>
>
>
>> I totally agree that generic and interoperable OAuth client 
>> implementations need both endpoint discovery and client registration. 
>>  I disagree that this spec needs registration.
>> This spec is about using OAuth on resource servers which have nothing 
>> to do with authentication and token issuance. 
>
> I agree these are different aspects. Does this mean they need to be 
> treated in different specs? What is the benefit of this approach?
>
> I'm not looking for a generic OAuth client. My goal is to enable the 
> development of generic email/calendar/xmpp ... clients, which 
> authorize access to the respective service using OAuth.
> Such a generic client must (at most) perform the following steps in 
> order to get access to the resource server:
>
> 5) if client is not in possession of suitable client credentials -> 
> register with the authz server (at the registration endpoint obtained 
> from the discovery document)
> This spec currently does not specify steps 4 through 6, which means 
> there is no way to implement the whole process in an interoperable way 
> in my generic email client. I therefore suggest to add registration to 
> this spec in order to cover the entire process.
>
>> We might need to talk about client registration requirements in a 
>> token profile, but this draft doesn't define new tokens either.
>
> There is no need to define new tokens as this is not relevant for 
> client/resource server interop. Resource server know the authz 
> server's token format (which is standard in OAuth deployments).
>
> kind regards,
> Torsten.
>
>
>>
>> On whether to specify the full OpenID Connect Discovery schema, I 
>> think a SHOULD is reasonable, I don't really like the MUST.
>>
>>
>> On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt 
>> <[email-masked]> <mailto:[email-masked]> wrote:
>>
>>
>> Hi all,
>>
>> > -16 is submitted, and there is one suggested change (which I was 
>> supposed to have added in already and blew it), which is to replace 
>> section 3.2.2 with the text (farther) below. My comments on the 
>> suggested text:
>>
>> > #1)  I don't think the dynamic registration stuff is baked enough 
>> to want to pull that in to the "oauth-configuration" definition. I 
>> don't want to pull it in because I don't think dynamic registration 
>> is required for SASL/OAUTH (as evidenced by the Google and 
>> Outlook.com implementations.
>>
>>
>> Existing implementations at Google and Outlook.com are no evidence 
>> against dynamic client registration. They demonstrate that it is possible
>> to implement the server side. But we are talking about clients (more 
>> precisely about generic clients). I'm not aware of any generic
>> client implementing the SASL mechanisms in the moment. I recommend 
>> taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540.
>>
>> Before I dive into the registration details, I would like to give my 
>> personal summary why this SASL profile is needed.
>>
>> In my opinion, one of the main purposes of this mechanism is to allow 
>> generic clients to authorize access to standard protocols, such as IMAP,
>> - multi-factor authn: An increasing number of service providers (e.g. 
>> Google, Yahoo, Apple) offer 2-factor authentication to their users,
>> but only for apps and web sites. Why? It currently does not work in 
>> conjunction with IMAP and the like. Instead, application-specific 
>> passwords
>> must be used, which offer a terrible user experience and therefore 
>> are a significant burden for better Internet security. Using OAuth 
>> access tokens
>> allows to decouple service access and authentication/authorization 
>> process. So the authorization server can choose the appropriate/available
>> mechanisms to authenticate at its discretion. This also allows to use 
>> any kind of (provider-specific) multi-factor authentication methods also
>> - Furthermore, using OAuth also allows to use refresh tokens as 
>> persistent credential for service login, that way eleminating the 
>> need to store user
>> passwords on devices.
>>
>> So basically, the SASL OAuth profile can (at least in my opinion) be 
>> a major leap forward in Internet security.
>>
>> Well, OAuth requires any client to possess a client_id (and 
>> client_secret) with the particular authorization server. Nowadays 
>> developers typically
>> register with the authz server's provider out of band and bake the 
>> credentials into the software package. This works for clients, which
>> are directly programmed against a certain deployment/API, such as 
>> Facebook, but is inappropriate (if not unfeasible) for generic
>> Or do you want to register the Thunderbird deveopers with every 
>> e-Mail/Calendar-provider in the world up-front?
>>
>> I don't think so. That's why the OAuth WG came up with the 
>> specification for dynamic client registration, which allows
>> the client to dynamically obtain client credentials from the 
>> authorization server. It basically solves the client credential 
>> challenge for generic
>> That's why I think we must define a way for a generic SASL client to, 
>> based on user-provided data, find the appropriate authorization 
>> server and
>> register with it. I think the SASL mechanism should specify how those 
>> mechanisms are used in concert in order to authorize service access 
>> using OAuth.
>> Otherwise, the SASL mechanism can only be used for point to point 
>> integrations among partners but never for generic clients.
>>
>> Regarding state of dynamic client registration: It's not ratified yet 
>> but already sent to IESG for publication.
>> > #2)  I didn't really want to make all of the OpenID elements 
>> required but I don't have a strong opinion here, my initial intent 
>> was to use the OpenID Discovery format as an existing format to be 
>> re-used here but leave it flexible.
>>
>> Agreed. Using the format as specified by OpenID Connect makes sense. 
>> As generic OAuth differs from OpenID Connect, the WG should (probably 
>> in cooperation with
>> > #3)  I am against recommending scope names at all in any way.  I 
>> would not include the last sentence of paragraph 5 below and strike 
>> the scope names.
>>
>>
>> Given there is already a response parameter scope, which intructs the 
>> client on what scope to use in the authz request, I tend to agree. 
>> I'm not yet fully

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 Oct 2014 11:46:40 -0700

+1

Phil

@independentid
www.independentid.com
[email-masked]

On Oct 15, 2014, at 11:06 AM, Torsten Lodderstedt <[email-masked]> wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Bill Mills <[email-masked]>
Date: Wed, 15 Oct 2014 18:47:42 +0000 (UTC)

I think that wants to be a draft that's more generalto OpenID and OAuth.  Agreed it's a good thing.

---

From: Bill Mills <[email-masked]>
Date: Thu, 16 Oct 2014 19:12:23 +0000 (UTC)

Based on the discussion here I've put together softer language that gives the right guidance but doesn't make major normative changes in the draft.

Section 1 Introduction -- second to last paragraph:
Again, steps (E) and (F) are not defined in [RFC6749] (but aredescribed in, for example, [RFC6750] for the OAuth Bearer Tokeninstead) and are the main functionality specified within thisdocument. Consequently, the message exchange shown in Figure 1 is theresult of this specification. The client will generally need todetermine the authentication endpoints (and perhaps the serviceendpoints) before the OAuth 2.0 protocol exchange messages in steps(A)-(D) are executed. The discovery of the resource owner, authorization server endpoints, and client registration are outside the scope of this specification. The client must discover the authorization endpoints using a discovery mechanism such as OpenIDConnect Discovery [OpenID.Discovery] or Webfinger using host-meta[RFC7033].  Once credentials are obtained the client proceeds to steps(E) and (F) defined in this specification.  Authorization endpointsMAY require client registration and generic clients SHOULD supportthe Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg].
(Note: I struck "In band discovery is not tenable if clients support the OAuth 2.0 password grant.)

Section 3.2.2 In the "oauth-configuration (OPTIONAL):" bullet add:
(appended to/after the first paragraph)
The returned discovery document SHOULD have all dataelements required by the OpenID Connect Discovery specificationpopulated.  In addition, the discovery document SHOULD containthe 'registration_endpoint' element to learn about the endpointto be used with the Dynamic Client Registration protocol[I-D.ietf-oauth-dyn-reg] to obtain the minimum number ofparameters necessary for the OAuth protocol exchange tofunction.  Another comparable discovery or client registrationmechanism MAY be used if available. 
The use of the 'offline_access' scope, as defined in[OpenID.Core] is RECOMMENDED to give clients the capability toexplicitly request a refresh token.

(At the end of this bullet)
Since clients may interact with a number of application servers,such as email servers and XMPP servers, they need to have a wayto determine whether dynamic client registration has been performedalready and whether an already available refresh token can bere-used to obtain an access token for the desired resource server.This specification RECOMMENDs that a client uses the information inthe 'issue' element to make this determination.

     On Wednesday, October 15, 2014 11:47 AM, Bill Mills <[email-masked]> wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 16 Oct 2014 17:10:05 -0400 (EDT)

Sorry for the long radio silence -- the thread started quickly, and I
didn't get a large block of time to digest it all until just now.

Torsten -- many thanks for sending out the motivation for talking about
discovery.  I agree that there is a real concern for getting true
interoperability, but am not fully decided on where it is best to put the
full description.

On Thu, 16 Oct 2014, Bill Mills wrote:

> Based on the discussion here I've put together softer language that
> gives the right guidance but doesn't make major normative changes in the
> draft.

In particular, I think I would be okay with text like Bill's proposal
here, noting that there will need to be discovery and registration
available, and giving some guidance for how to do so, but referring to
other documents rather than putting lots of detail in this document.  That
is, I think it is okay for this document to retain a limited scope, so
long as it notes what other pieces will be required in order to implement
an application that is sufficiently generic.

-Ben

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 18 Oct 2014 19:26:21 +0200

Hi Bill,

reads like a good consensus.

kind regards,
Torsten.

Am 16.10.2014 21:12, schrieb Bill Mills:
> gives the right guidance but doesn't make major normative changes in 
> the draft.
>
>
> Again, steps (E) and (F) are not defined in [RFC6749] (but are
> described in, for example, [RFC6750] for the OAuth Bearer Token
> instead) and are the main functionality specified within this
> document. Consequently, the message exchange shown in Figure 1 is the
> result of this specification. The client will generally need to
> determine the authentication endpoints (and perhaps the service
> endpoints) before the OAuth 2.0 protocol exchange messages in steps
> (A)-(D) are executed. The discovery of the resource owner,
> authorization server endpoints, and client registration are outside
> the scope of this specification. The client must discover the
> authorization endpoints using a discovery mechanism such as OpenID
> Connect Discovery [OpenID.Discovery] or Webfinger using host-meta
> [RFC7033].  Once credentials are obtained the client proceeds to steps
> (E) and (F) defined in this specification.  Authorization endpoints
> MAY require client registration and generic clients SHOULD support
> the Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg].
>
> The returned discovery document SHOULD have all data
> populated.  In addition, the discovery document SHOULD contain
> function.  Another comparable discovery or client registration
> mechanism MAY be used if available.
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 21 Oct 2014 21:49:16 +0000 (UTC)

Based on this and Torsten's apparent +1 should I put out a new draft?
Thanks,
-bill 

     On Thursday, October 16, 2014 2:10 PM, Benjamin Kaduk <[email-masked]> wrote:

-Ben

---

From: Shawn M Emery <[email-masked]>
Date: Tue, 21 Oct 2014 17:14:53 -0600

> Based on this and Torsten's apparent +1 should I put out a new draft?

I've volunteered to be the shepherd for this document and I have not yet 
submitted this draft to the IESG.  So feel free to rev the draft, but I 
think the changes would justify another WGLC.  This is based on the 
assumptions of what is not in scope for this draft.

Shawn.
--
kitten co-chair

---

From: Bill Mills <[email-masked]>
Date: Wed, 22 Oct 2014 00:52:44 +0000 (UTC)

how does the inclusion of working drafts rather than finished drafts affect the process?  Inclusion of the dynamic registration stuff would do that. 

     On Tuesday, October 21, 2014 4:23 PM, Shawn M Emery <[email-masked]> wrote:

 
 I've volunteered to be the shepherd for this document and I have not yet submitted this draft to the IESG.  So feel free to rev the draft, but I think the changes would justify another WGLC.  This is based on the assumptions of what is not in scope for this draft.
 
 Shawn.
 --
 kitten co-chair

 

 
 
 -Ben

---

From: Bill Mills <[email-masked]>
Date: Wed, 22 Oct 2014 01:04:45 +0000 (UTC)

Do you have any opinion on the changes? 

  

 Shawn.
 --
 kitten co-chair

 

 
 
 -Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Oct 2014 15:28:39 -0400 (EDT)

On Tue, 21 Oct 2014, Bill Mills wrote:

> how does the inclusion of working drafts rather than finished drafts
> affect the process?  Inclusion of the dynamic registration stuff would
> do that.

To some extent it depends on the specifics; if I understand correctly, in
the general case, if draft A makes a normative reference to draft B, then
draft A can be approved by the IESG for publication, but does not get
actually published by the RFC Editor until draft B is also approved, so
they get published in the same batch.  Such a dependency wouldn't
necessarily hold up our WG work on it.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Mon, 27 Oct 2014 20:27:18 +0000 (UTC)

Is it fair to say the discovery docs are informative rather than normative?  I think so because they are SHOULD rathe rthan MUST. 

     On Monday, October 27, 2014 12:28 PM, Benjamin Kaduk <[email-masked]> wrote:

-Ben

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 27 Oct 2014 14:35:54 -0600

On 10/27/14, 2:27 PM, Bill Mills wrote:
> Is it fair to say the discovery docs are informative rather than 
> normative?  I think so because they are SHOULD rathe rthan MUST.
> 
> 

/me doffs hat

SHOULD means "do it unless you understand unless you have a good
reason (and understand the consequences) to not do it."

To me, that would mean you have to understand the "it", to know if you
understand have a good reason (and understand the consequences) to not
follow the SHOULD.  If you have to understand something, then which
(to me) means it's normative.

The decision on whether or not a reference is normative can't be based
on whether its publication is impacted, but on if it's important to
understand the referenced material before one can implement the given
specification.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

>> how does the inclusion of working drafts rather than finished
>> drafts affect the process?  Inclusion of the dynamic registration
>> stuff would do that.
> 
> To some extent it depends on the specifics; if I understand
> correctly, in the general case, if draft A makes a normative
> reference to draft B, then draft A can be approved by the IESG for
> publication, but does not get actually published by the RFC Editor
> until draft B is also approved, so they get published in the same
> batch.  Such a dependency wouldn't necessarily hold up our WG work
> on it.
> 
> 
> -Ben
> 
> 
> 
> 
> _______________________________________________ Kitten mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 28 Oct 2014 22:20:02 +0000 (UTC)

Thanks for the color there, I think that's a fair characterization of normative vs. informative.  Attached is my -17 current cut.  Window has closed for publication already I guess.  Posted for discussion.
-bill

     On Monday, October 27, 2014 1:35 PM, ⌘ Matt Miller <[email-masked]> wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

/me doffs hat

- -- 
- - m&m