Re: Withdrawing sponsorship of draft-housley-tls-authz-extns

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

 



> > I'm not sure whether I agree with your proposal or not, but I
> > think
> > the most concrete way forward would be a proposal for specific
> > wording for draft-narten-iana-considerations-rfc2434bis, which
> > Harald left on my plate and I left for Russ.

That document is pretty much done. Indeed, it may be done. I had
folded in some comments from IANA on the last respin. I'll have to
check my notes to see if there is any other outstanding comment. My
bad for not getting the process finished.

> And that last clause -- i.e., the fact that document has not 
> progressed in three years or more -- may suggest either that (i) 
> if modifying it is the most constructive way forward, we have a 
> problem or (ii) that it is not an effective way forward, whether 
> or not it is constructive.

IMO, completing this document is long overdue. It is a tremendous
improvement over 2434.

Some general comments on this thread. I understand the argument that
some make that we should just give out code points in all cases,
because otherwise we invite squatting. On the other hand, I do believe
that withholding code points does prevent (in some, but not all cases)
use of extensions that are potentially problematical. As one concrete
example, other SDOs are generally hesitant to endorse/use protocols
that have not been properly granted code points. This has been a
carrot/stick in the past to get those SDOs to come to the IETF with
the work rather than just having them "embrace and extend" our
protocols. Do you think this is not useful/necessary or that it can be
done in other ways?

Also, if one thinks that code points should just be given out in all
cases, how do we deal with stuff like RFC 3427? 

And, does this also mean, for example, that anyone should be granted
ICMP code points?

Are you really calling for essentially granting code points to anyone
who asks? (That is what I hear when the bottom line is that the IETF
can't say no, because, the reality is (IMO) that some only come to the
IETF because they have to. They'd just as soon do their own thing and
don't appreciate having their proposals get seriously reviewed.)

Thomas

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]