[AFS3-std] Re: A call for consensus on draft-brashear-afs3-pts-extended-names-07
Tom Keiser
tkeiser@gmail.com
Fri, 17 Dec 2010 15:04:33 -0500
--001636c5c241cd14260497a0addc
Content-Type: text/plain; charset=ISO-8859-1
On Dec 17, 2010 1:20 PM, "Jeffrey Altman" <jaltman@your-file-system.com>
wrote:
>
> On 12/17/2010 12:59 PM, Simon Wilkinson wrote:
>
> > My feeling is that both of these comments concern implementation
specific issues. In addition, I think they've been raised very late. The
mapping language has existed within this document since the first draft,
originally published in April of this year. There have been numerous calls
for review on this list since then.
> >
> > My belief is that Last Call should be a place for those who feel that
earlier remarks have been ignored to raise their grievances, and for those
who have only just reviewed the document to raise major concerns. I'm not
convinced that they're an appropriate location for these kinds of minor
issues which should have been raised much earlier in the process.
> >
> > Otherwise, why should anyone bother reading a document before Last Call?
> >
>
> I raised the issue yesterday because my concern was literally brought to
> my attention yesterday by an organization with a large AFS cell that is
> trying to migrate off of krb524d. krb524d is currently in use because
> it provides a user principal name mapping built upon the use of wildcards.
>
> I believe that Andrew's feedback is completely appropriate for a last
> call. The lack of a definition of "implicit mapping" vs "explicit
> mapping" is not something that most readers would notice because I'm
> sure that all of us just assume that we know what is meant. It is only
> when someone attempts to implement the specification that most
> ambiguities are uncovered. I would rather have someone discover a
> weakness during Last Call than not have it discovered until after a
> document is published.
>
> My interpretation of explicit mappings are those mappings that can be
> added, viewed and modified using the protocol specified in this
> document. Implicit mappings are those that are implemented in an
> implementation specific manner such that they are invisible to the user
> of this specification. One example of such implicit mappings are the
> krb5 to krb4 principal mappings built-in to OpenAFS rxkad.
>
> I propose that we agree upon a definition to be added to the existing
> document and conclude the Last Call since there appear to be no other
> outstanding issues.
>
I Agree: this is the best resolution.
-Tom
--001636c5c241cd14260497a0addc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p><br>
On Dec 17, 2010 1:20 PM, "Jeffrey Altman" <<a href=3D"mailto:j=
altman@your-file-system.com">jaltman@your-file-system.com</a>> wrote:<br=
>
><br>
> On 12/17/2010 12:59 PM, Simon Wilkinson wrote:<br>
><br>
> > My feeling is that both of these comments concern implementation =
specific issues. In addition, I think they've been raised very late. Th=
e mapping language has existed within this document since the first draft, =
originally published in April of this year. There have been numerous calls =
for review on this list since then.<br>
> ><br>
> > My belief is that Last Call should be a place for those who feel =
that earlier remarks have been ignored to raise their grievances, and for t=
hose who have only just reviewed the document to raise major concerns. I=
9;m not convinced that they're an appropriate location for these kinds =
of minor issues which should have been raised much earlier in the process.<=
br>
> ><br>
> > Otherwise, why should anyone bother reading a document before Las=
t Call?<br>
> ><br>
><br>
> I raised the issue yesterday because my concern was literally brought =
to<br>
> my attention yesterday by an organization with a large AFS cell that i=
s<br>
> trying to migrate off of krb524d. =A0krb524d is currently in use becau=
se<br>
> it provides a user principal name mapping built upon the use of wildca=
rds.<br>
><br>
> I believe that Andrew's feedback is completely appropriate for a l=
ast<br>
> call. =A0The lack of a definition of "implicit mapping" vs &=
quot;explicit<br>
> mapping" is not something that most readers would notice because =
I'm<br>
> sure that all of us just assume that we know what is meant. =A0It is o=
nly<br>
> when someone attempts to implement the specification that most<br>
> ambiguities are uncovered. =A0I would rather have someone discover a<b=
r>
> weakness during Last Call than not have it discovered until after a<br=
>
> document is published.<br>
><br>
> My interpretation of explicit mappings are those mappings that can be<=
br>
> added, viewed and modified using the protocol specified in this<br>
> document. =A0Implicit mappings are those that are implemented in an<br=
>
> implementation specific manner such that they are invisible to the use=
r<br>
> of this specification. =A0One example of such implicit mappings are th=
e<br>
> krb5 to krb4 principal mappings built-in to OpenAFS rxkad.<br>
><br>
> I propose that we agree upon a definition to be added to the existing<=
br>
> document and conclude the Last Call since there appear to be no other<=
br>
> outstanding issues.<br>
></p>
<p>I Agree: this is the best resolution.</p>
<p>-Tom</p>
--001636c5c241cd14260497a0addc--