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


To: ietf-provreg@cafax.se
From: Andrew Sullivan <andrew@ca.afilias.info>
Date: Tue, 16 Aug 2005 17:22:02 -0400
Content-Disposition: inline
In-Reply-To: <a06200711bf27f3d2f1ae@[10.31.32.63]>
Mail-Followup-To: Andrew Sullivan <andrew@ca.afilias.info>,ietf-provreg@cafax.se
Reply-To: Andrew Sullivan <andrew@ca.afilias.info>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.5.9i
Subject: Re: [ietf-provreg] 3730 <poll> Text Change Proposal

On Tue, Aug 16, 2005 at 04:02:07PM -0400, Edward Lewis wrote:
> 
> The change confuses me.  Instead of relaxing from MUST to SHOULD, the 
> change eliminates any "standards" words.

I think others have pointed out that any relaxing from MUST will not
make existing code incompatible with the resulting document.  

I don't want to attribute anything to Scott (since I have no
knowledge in this matter -- or in any other, some would argue!), but
I have a suspicion that the use of "can" instead of any of the magic
standards words is a feature, not a bug.  I think it's a good idea,
because it neatly sidesteps the problems we've identified in the use
of the poll queue, and doesn't potentially embroil us in other
standards issues.

> The code base we have currently conforms to the "OLD" spec.  We don't 
> have a problem with it, hence we are reluctant to want to see the 
> spec changed (in a way that is "not backwards compatible").  Not so 

I can understand a desire to avoid changes that cause
incompatibilities (even if this isn't such a case).  But I think this
is a weak plank on which to build an argument that the protocol needs
to remain unchanged.  The whole point of PROPOSED STANDARD after all
is that we're not completely committed to that design, precisely
because we're aware that we might not have had all the operational
experience necessary to get things quite right when folks were first
designing the protocol.  That isn't to say I think we should embrace
change for its own sake; I prefer to leave the protocol alone, to the
extent possible, and use extensions where we can, even if the result
is not the most elegant approach when considered in isolation.  I'm
just made awful nervous by a suggestion that we shouldn't fix things
we find need fixing (if we do -- and I recognise the jury is still
out) because we have some installed base.  It'll be much harder to
fix things later, with a bigger installed base.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110


Home | Date list | Subject list