Re: (long/architectural version) Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

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

 



> On 26 Feb 2015, at 00:14, Mark Andrews <marka@xxxxxxx> wrote:
> 
>> (1)  Integrity of the standards process.
>> 
>> For many years, it was a key IETF principle that standardization
>> of a particular technology meant that the community had been
>> able to review all of the details, make changes where needed,
>> and then reach rough consensus on the result.  The notion of
>> registering an RRTYPE via Expert Review and then turning around
>> and asking that it be standardized while claiming that details
>> (or even design principles) cannot be changed because it is
>> already registered and in use represents a fundamental departure
>> from and threat to our historical standardization model.  No
>> malice is implied here, just a bad sequence of steps.   I don't
>> know that it makes a lot of difference how this particular spec
>> is classified, but, noting that the same situation could apply
>> to a number of other specifications where registration is by
>> expert review (Media Types come to mind as do URIs and, if
>> 2141bis is approved in more or less its current form, URNs), it
>> seems to me that the IETF needs to address this issue, perhaps
>> confining specifications for already registered names to
>> Informational or Experimental categories and figuring out an
>> alternative to expert review for specs that people will want on
>> the standards track.
> 
> There is no requirement to use expert review.  The full blown rfc
> process is still available.  If you use expert review however the
> format of the record is fixed when the review is done.  [ For the
> record the format of the record changed which was annoying for those
> of us that wrote explict code to handle the type.  The reference
> for the type will need to be updated if it hasn't been done. ]

I think there are a number of things we have problems with in the IETF. Like cross-area-review and because of this design. Each area look at things from their perspective and hold hard to their ideas on the future of the world.

In this specific case, sure, like many other definitions by IETF it was not optimal when the review happened, but maybe it is wrong to have the later published RFC on standards track as it seems to end up? Maybe it should be "just" informational (if that matters).

Regarding the change that Mark point out in this case, the clarification that was made from an earlier draft to what we now have have are I claim not incompatible with what is in the application for an RRType that was applied for. The difference is that we now clarify that the URI is "just bytes" to the end of the RDATA field. It is not an (as defined in DNS) text string which has limited length. I.e. we all remember a TXT RRType can have multiple text strings in the RDATA field.

This clarification was made in cooperation and in coordination with people that implement URI (which was when this was discovered).

At least that is what I think you do talk about Mark?

   Patrik

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


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