Olaf Kolkman | 1 Jul 2005 08:35
Picon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.

(Continue reading)

Eastlake III Donald-LDE008 | 4 Jul 2005 18:46

RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

See below at  <at>  <at>  <at> 

-----Original Message-----
From: Edward Lewis [mailto:Ed.Lewis <at> neustar.biz] 
Sent: Wednesday, June 29, 2005 10:31 AM
To: Eastlake III Donald-LDE008
Cc: namedroppers <at> ops.ietf.org; Ed.Lewis <at> neustar.biz
Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

This message demarcation thing is a pain ;) so I've taken the liberty 
of removing the old context...

At 20:58 -0400 6/28/05, Eastlake III Donald-LDE008 wrote:

>Well, the current criteria for these parameters in RFC 2929 is "IETF
>Consensus". RFC 2434 defines that as "new assignments are made via RFCs
>approved by the IESG". So any change is likely to *reduce* the theoretic
>load on the IESG. As to which working group the intent is the working group
>whose protocol needs the value.

Either way, I think we ought to be shielding the IESG from having to 
make operational (in the sense of moving the bureaucracy along) 
decisions.  OTOH, if there is no DNS WG, I am not sure the other WGs 
are really prepared to make DNS related decisions - and in that case 
it falls to the shepherding AD anyway.

 <at>  <at>  <at>  The IESG is where the bulk of the athority and responsibility is in the IETF. There are limits as to how far
we can "shield" them and, I'm sure, limits to the extent to which they want to be cut out of things. If we make
Early Allocation of these DNS code points for WGs depending on WG consensus plus AD approval, I suppose we
could, for individual requests, just require approval of two ADs...
(Continue reading)

Olaf M. Kolkman | 5 Jul 2005 09:32
Picon
Favicon

Cross Area Review: draft-ietf-hip-dns-01


Dear colleagues,

Help from this group on reviewing draft-ietf-hip-dns-01 would be highly 
appreciated. 

Also see:
  http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00863.html

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Edward Lewis | 5 Jul 2005 21:29
Favicon

RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

At 12:46 -0400 7/4/05, Eastlake III Donald-LDE008 wrote  <at>  <at>  <at> :

> <at>  <at>  <at>  I'm not too enamored for technical criteria for "innocuous" RR
> <at>  <at>  <at>  definitions. I'd generally oppose requiring IANA to make technical
> <at>  <at>  <at>  judgements.

The point of documenting criteria is to avoid the need for judgements.

>Relying on a personality (as opposed to a person) to do a job does
>not scale - not in volume nor in time.
>
> <at>  <at>  <at>  Sure it does. Everything has either one person in change, like the
> <at>  <at>  <at>  Administrator of the (US) Federal Aviation Agendy, or a committee, like
> <at>  <at>  <at>  the (US) Federal Communications Commission. If they have too much to do,
> <at>  <at>  <at>  they rrecruit helpers or delegate to staff.

The difference is between a "personality" and a "person in charge." 
To me, "personality" generally means that the person involved is 
inventive, a "person in charge" is a person making sure steps are 
checked off - whether that's a literal bureaucratic checklist or a 
sketchy details list.

For scaling, you want a "person in charge" (or "person responsible") 
and not a "personality."

(There's an expression "cult of personality" but there's no "cut of 
'person in charge.'")

> <at>  <at>  <at>  I'm not entirely sure what you are saying here. If people can get an RFC
> <at>  <at>  <at>  into the RFC Editor's queue, they should be able to get a permanent type
(Continue reading)

Edward Lewis | 6 Jul 2005 17:00
Favicon

new version of wcard coming

In response to a gaggle of last call comments, another version was 
sent to the drafts- repository.  It should appear any day now.

There's a table of contents, but no pagination yet...that'll come last.
--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Margaret Wasserman | 7 Jul 2005 05:41
Favicon

NEW!! Internet Area Mailing List


[This message is bcc:ed to all INT area WGs, the IESG and the IAB.]

Hi All,

We have created an Internet Area mailing list -- int-area <at> ietf.org. 
This list will be used to announce Internet area BOFs, to discuss 
Internet area WG charter updates and to discuss other issues related 
to the Internet Area, as they arise -- such as whether we should hold 
an Internet area meeting in Paris.

If you wish to join the list, you can do so at:

https://www1.ietf.org/mailman/listinfo/int-area

The archives should be available at:

http://www.ietf.org/mail-archive/web/int-area/index.html

(Hopefully this will be the first message in the archive).

If you are interested in issues concerning the overall structure or 
scope of the Internet area and/or are interested in influencing how 
the Internet area is managed, I hope you will join this list.

Thanks,
Margaret

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
(Continue reading)

Eastlake III Donald-LDE008 | 7 Jul 2005 06:35

RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

Ed,

I think our discussion is headed off into a philosophical direction in areas where we seem to disagree. But,
I don't think resolving all these questions is necessary to come to some consensus on what should be in 2929bis.

See below at ###

-----Original Message-----
From: Edward Lewis [mailto:Ed.Lewis <at> neustar.biz] 
Sent: Tuesday, July 05, 2005 3:29 PM
To: Eastlake III Donald-LDE008
Cc: namedroppers <at> ops.ietf.org; 'Edward Lewis'
Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

At 12:46 -0400 7/4/05, Eastlake III Donald-LDE008 wrote  <at>  <at>  <at> :

> <at>  <at>  <at>  I'm not too enamored for technical criteria for "innocuous" RR
> <at>  <at>  <at>  definitions. I'd generally oppose requiring IANA to make technical
> <at>  <at>  <at>  judgements.

The point of documenting criteria is to avoid the need for judgements.

### "Judgments" was probably the wrong word. Perhaps I should have said "technical assessments". If there
are technical criteria, you have to either (1a) assume these criteria are absolutely unambiguous and
(1b) that all applicants are absolutely honest in self assessing whether they meet those criteria, or (2)
have an authority that makes technical assessments. I content that there are problems with 1. 2 isn't
terrible but the current ideal for IANA is, as far as I can tell, that IANA should be able to act as a clerk. The
main exception seems to be the Specification Required IANA consideration which required the technical
judgment as to whether a specification is adequate for interoperability, a judgment that I suspect IANA
currently refers to a technical expert they select.
(Continue reading)

Edward Lewis | 7 Jul 2005 15:41
Favicon

RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

At 0:35 -0400 7/7/05, Eastlake III Donald-LDE008 wrote:

>I think our discussion is headed off into a philosophical direction in areas
>where we seem to disagree. But, I don't think resolving all these questions
>is necessary to come to some consensus on what should be in 2929bis.

The questions for the document are:

Can we allow coders to burn a number into code early in the 
development cycle and then lock that same number into the registry 
after review?

What is the review?  Who does it, what is looked at, how is it make 
public (so no other coders pick the same number)?

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

william(at)elan.net | 7 Jul 2005 16:17

RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt


On Thu, 7 Jul 2005, Edward Lewis wrote:

> At 0:35 -0400 7/7/05, Eastlake III Donald-LDE008 wrote:
>
>> I think our discussion is headed off into a philosophical direction in 
>> areas
>> where we seem to disagree. But, I don't think resolving all these questions
>> is necessary to come to some consensus on what should be in 2929bis.
>
> The questions for the document are:
>
> Can we allow coders to burn a number into code early in the development cycle 
> and then lock that same number into the registry after review?

Not for internal testing within one organization. But if they want their
code used in experimental way by multiple parties on the internet than
they should be allowed to do it.

And note that experimental should not mean published experimental RFC
but I think we should at least expect internet draft or some other 
similar type document publicly available.

> What is the review?  Who does it, what is looked at, how is it make public 
> (so no other coders pick the same number)?

One way is to require them to register the number in provisional way
(with very quick - within 30 days registration by IANA for very limited
period), but provisional registration would be very brief, something
like 6-12 months and continuing provisional registration longer then
(Continue reading)

Olaf M. Kolkman | 7 Jul 2005 13:23
Picon
Favicon

Re: Cross Area Review: draft-ietf-hip-dns-01


 [ Moderators note: Post was moderated, either because it was posted by 

  a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
 Please fix your subscription addresses. ]

On Tue, 5 Jul 2005 09:32:48 +0200
olaf wrote to namedroppers:
> 
> Help from this group on reviewing draft-ietf-hip-dns-01 would be highly 
> appreciated. 

Hello Julian and Pekka,

I've CC-ed namedroppers to avoid to much duplication of effort.

I'v read your document and most issues are "style" issues. I have not
read the other HIP docs recently and I tried to understand this
document as "self-contained", some of my remarks come from that.

There are some "real" DNS issues that can be easilly dealth with. I've
tried to provide document text wherever I could.

Comments are in-line. I've tried to mark my comments starting with on
lines with "*"

Albeit the comments this is a very readable and complete document,
congrats!
(Continue reading)


Gmane