[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Edward Lewis" <Ed.Lewis@Neustar.biz>
Cc: <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Fri, 12 Aug 2005 14:53:15 -0400
Content-class: urn:content-classes:message
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcWfam6kkr4hI5x+S66GwXonpVm+fgAA8qBQ
Thread-Topic: [ietf-provreg] Services messages in RFC 3730
Subject: RE: [ietf-provreg] Services messages in RFC 3730

> -----Original Message-----
> From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] 
> Sent: Friday, August 12, 2005 2:20 PM
> To: Hollenbeck, Scott
> Cc: Michael Young; ietf-provreg@cafax.se
> Subject: RE: [ietf-provreg] Services messages in RFC 3730

[snip]

> >c. It's common IETF practice to add new features via extensions once
> >proposed standards are published.  Extension development is usually a
> >good reason to spin up a new working group.
> 
> On a tangent - do you mean to say that extensions ought to cause a 
> new WG?  Up to now some extensions haven't been discussed in a (new) 
> WG.

What I'm saying is that it's not uncommon for a new group to form around
the idea of adding new features to an established protocol without
changing the established protocol.  The imapext working group, for
example.  There generally has to be a lot of common ground among the
implementing community to have this be successful.  In our case, it
could mean that multiple people would want to work on the same
extension(s), maybe due to an ICANN requirement or some other similar
need that brings people together.

It's also quite acceptable for someone to just write their own extension
draft and push it through the standards process.  This is probably a
better option if the extension has limited appeal.

-Scott-


Home | Date list | Subject list