Re: Updating the rules?

[Brian E Carpenter]

On 2007-07-07 08:30, Keith Moore wrote:

Also from the draft:
"At least for the strong security requirement of BCP 61 [RFC3365], the
Security Area, with the support of the IESG, has insisted that all
specifications include at least one mandatory-to-implement strong
security mechanism to guarantee universal interoperability."

I do not think this is a factual statement, at least when it comes to
HTTP, which is where my interest lies.

note that it is not necessary to have at least one
mandatory-to-implement strong security mechanism to guarantee
interoperability.  consider, for example, a client-server protocol for
which conforming servers are required to implement
_two_ strong security methods and for which clients are required to
implement _at least one_ of those two methods.  this
would ensure interoperability even though there were no single
mandatory-to-implement for clients.

depending on the circumstances, putting a greater burden on the server
than the client, or vice versa, might make sense.


As far as 2026bis goes, my idea would be to have language that defines
the bounding requirements. There are specifics in BCP 61 = RFC 3365
which would be out of place in 2026bis.

In the above quote I would suggest
s/to guarantee universal interoperability/in the interests of universal 
interoperability/

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Draft ION about our rules in practice

[Brian E Carpenter]

I posted
http://www.ietf.org/IESG/content/ions/drafts/ion-2026-practice.html
at Russ Housley's request.

"This document discusses how RFC 2026, the current description
of the IETF standards process, operates in practice. Its main
purpose is to document, for information only, how actual practice
interprets the formal rules."

Comments on errors of fact are welcomed.

Note that this is intended to be orthogonal to
draft-carpenter-rfc2026-changes-00.txt

Brian



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Updating the rules?

[Brian E Carpenter]

I posted draft-carpenter-rfc2026-changes-00.txt at
Russ Housley's request. Obviously, discussion is very much
wanted.

Brian

http://www.ietf.org/internet-drafts/draft-carpenter-rfc2026-changes-00.txt

   This document proposes a number of changes to RFC 2026, the basic
   definition of the IETF standards process.  While some of them are
   definite changes to the rules, the intention is to preserve the main
   intent of the original rules, while adapting them to experience and
   current practice.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Putting technology on the table [Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt]

[Brian E Carpenter]

Micahel,

On 2007-07-04 16:52, [EMAIL PROTECTED] wrote:

That MPLS with 6PE is a superior migration scenario.
Or perhaps, that defining migration scenarios without the full  
involvement of network operations people is an exercise in  futility.


If the lesson we have learned is that the only practical way 
to handle and route IP (whether v4, v6, or otherwise) 
requires the use of an underlying virtual circuit layer, then 
much of what we are doing in the IETF involves an 
architectural delusion about the fundamental datagram and 
packet model of the Internet. 


All that the IETF can do is to put the technology on the table. It is up
to network operators, public and private (and very private) to try it
out, test the limits, point out bugs to be fixed, and ultimately accept
or reject it. Over the past 8 or 9 years, this is just what many
operators have been doing with MPLS and the verdict is that MPLS works
very well indeed. Unfortunately, we have been a bit shortsighted in not
realizing that we cannot live with only MPLS and IPv4 because we will
run out of new IPv4 addresses by 2010.

But, given that MPLS works and works very well, it seems to me that a
viable migration scenario is NOT to throw away MPLS and attempt to make
pure IPv6 work right away, but to start with 6PE at the edge where most
growth occurs (in terms of connections) and where we can run a viable
business selling IPv6 services to financially support migration
activities.


I don't understand the tone of complaint in the above. The IETF *has*
put 6PE on the table: RFC 4798 is a Proposed Standard. That's where
the IETF's role ends - this is one of the mechanisms for IPv6
coexistence, among which the market can choose.

  Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt

[Brian E Carpenter]

Or perhaps, that defining migration scenarios without the full
involvement of network operations people is an exercise in futility. 


It would have been, if v6ops had done that.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-natpt-to-historic-00.txt

[Brian E Carpenter]

BTW, people who want to help fix this topic could usefully
hop over to v6ops and comment constructively on
draft-ietf-v6ops-cpe-simple-security-00.txt and
draft-woodyatt-ald-01.txt.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt

[Brian E Carpenter]

There is no other device that can provide me with a lightweight firewall for 
$50.


Yes there is; it's a SOHO gateway with its NAT function switched
off for use with a "fixed IP address".

SOHO gateways with IPv6 support will provide exactly as much firewall
protection as a NAT-capable IPv4 SOHO gateway. The only question is
when they will cost $50.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IPv6 transition technologies

[Brian E Carpenter]

On 2007-07-01 18:56, Jun-ichiro itojun Hagino wrote:

NAT-PT really needs to be wiped off the face of the earth.  It provides
all of the disadvantages of IPv4+NAT with all of the transition costs of
IPv6.  If there is ever any significant penetration of NAT-PT, then the
pseudo-IPv6 network will not be able to support any more kinds of
applications than the NATted IPv4 does today.


i tend to agree, but in rfc-index.txt i could not find the change of
state to "Historic".  what happend to very similar (and much more evil
IMHO) transition technology, SIIT?


If you look at draft-ietf-v6ops-natpt-to-historic-00.txt (the
draft that obsoletes NAT-PT), it is quite critical of SIIT
(RFC 2765), but does not obsolete it.

[I attempted to obsolete SIIT before it was written (RFC 1671
section B) but that didn't work :-) . There are parts of
RFC 1671 that are wrong, but not that part.]

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)

[Brian E Carpenter]

On 2007-06-27 17:42, Michael Thomas wrote:

Brian E Carpenter wrote:

One thing that would make a significant difference would be if WGs
really took responsibility for their own quality control. Even at the
trivial level, the IESG still gets drafts that don't pass ID-nits
(but that is getting better, thanks to PROTO shepherding). But maybe
we should be pushing harder to make WGs responsible for getting
final external reviews done (and responded to). That would just be
more delegation along the path that's been followed for the last
several years.


Part of the problem with cross area review is that there's such a flood
of documents that it's pretty impossible to know unless somebody tells/asks
you to review it that you should care.


Indeed. The current reviews such as Gen-ART and secdir reviews don't just
happen spontaneously; specific reviewers are triggered by a "dispatcher."

As I said, I'm a little skeptical 
about
"expert review", but for so-called experts as well as the laity in other 
areas,

it might be nice to have some indexing when it touches areas which are
known to contain land mines.


We also need reviewers to look for land mines in unexpected places.



We already do this to some degree with Security Considerations, but they
often read as a "Full Disclosure" part of a contract rather than the 
basis of

how operation security is intended in the draft itself.

What might be nice is to have some cross domain Cliff's Notes capturing
the jist of how this draft uses or affects other areas? So that people 
in other

areas can determine more easily if something whacky might be going on
and pique their interest in reading it? Were this done sooner in the 
process

rather than later, we well might be able to nip more whackiness before it
bubbles all the way up to the IESG.


It sounds like that would be done before passing the document
on for AD review. Is that your idea?

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)

[Brian E Carpenter]

On 2007-06-27 20:46, Tony Li wrote:



I don't see increasing the areas; I see splitting them down as a
possible way. Leaving an AD at the top level with less work, and having
sub-ADs report to them.



It's well known that when dealing with a scalability issue, the way to 
address the issue is to install hierarchy.  [Have you ever heard me say 
this before?  ;-)]  Adding another layer of management  is therefore the 
obvious approach and a fine alternative to having co-ADs or more areas.


The downside to this is increased inefficiency and disconnect from reality.


I think the other issue is that this layer would be hard to fill in
our volunteer community. Being a WG Chair has its satisfactions, as does
being an AD or IAB member; I'm not quite sure what the satisfactions
in an intermediate position would be. That's why I'd rather push
work and responsibility into the 120 WGs, where there should be
compensating satisfaction in work well done.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)

[Brian E Carpenter]

On 2007-06-27 15:52, Joe Touch wrote:


Keith Moore wrote:

We could have more ADs and split and/or layer the work to reduce the
per-person load. That may not be the only - or even best - way forward,
  

It's not clearly even a way forward.  the more ADs there are, the harder
it is to coordinate between the ADs and the areas.


Yes, each AD becomes less efficient, but perhaps the goal shouldn't be
the efficiency of the individual volunteers but the ability to be more
inclusive in who we can consider for these roles.


It isn't an issue of individual efficiency. A committee of 15 is already
unwieldy given our desire for consensus; the IESG thought long and
carefully before the last increase (from 6 to 7 Areas). I don't see
how it can be increased further.

One thing that would make a significant difference would be if WGs
really took responsibility for their own quality control. Even at the
trivial level, the IESG still gets drafts that don't pass ID-nits
(but that is getting better, thanks to PROTO shepherding). But maybe
we should be pushing harder to make WGs responsible for getting
final external reviews done (and responded to). That would just be
more delegation along the path that's been followed for the last
several years.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)

[Brian E Carpenter]

Joe,

On 2007-06-24 18:19, Joe Touch wrote:


Ted Hardie wrote:
...

That does not mean the IETF leadership is itself a meritocracy; it's not.


I believe there remains a disconnect between what people think the I*
roles are (primarily service, e.g., IMO), 


That may be your opinion. Mine is that the part which is pure service
is exactly the part we should pay to get done, via contracts and SLAs
with IASA. If we had more money, I could certainly envisage paying for
a full-time Standards Process Manager, to actively manage document
and milestone processing. The part we expect from community members
placed in leadership positions is not that. It's the part that requires
technical breadth and depth, sound judgement, people skills and, er,
leadership.


and what those in those roles
have sometimes interpreted it as (oversight based on meritocracy).


Maybe, but Nomcom isn't supposed to re-appoint those...




The IESG and IAB are picked by NomComs for a variety of skills and
"fit" is a critical one. 


Indeed. The primary metric of "fit" means:

- is willing, available, and *financially* able to serve

Until we remove that last metric - where roles can take upwards of 80%
of someone's time, where letters of support from employers are
requested, if not required, we select from among an increasingly small
and increasingly biased (towards industry participants) subset.


Unfortunately I can't see any practical way to change this unless
we decide that instead of 120 WGs we should have, say, 50. I did
tentatively propose splitting the Chair role, but people didn't
bite on that, and it wouldn't solve the load problem for the IESG
as a whole.

   Brian



Those selected to serve would serve us all better if they kept that in
mind more often.

Joe





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ABNF third-party rights as code (BCP78)

[Brian E Carpenter]

On 2007-06-19 11:11, Dave Cridland wrote:
...


The more interesting question is whether the authors of those RFCs with 
ABNF in them intended the ABNF to be treated as code, or at least don't 
object. If RFC authors *do* object, then we have a more serious problem. 
But, at least so far in this thread, nobody has - I wondered if that 
might be because it's hidden in a thread apparently concerned with IMAP 
URLs, hence the change of subject line.


Thanks for that. "When you change the subject, please change the Subject."

I suggest people who are interested in this should read section 6.3
of draft-ietf-ipr-outbound-rights-03 and if they disagree,
say so on the IPR WG list.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Reforming the BOF Process (was Declining the ifare bof for Chicago)

[Brian E Carpenter]

On 2007-06-18 00:44, Bernard Aboba wrote:
...

The IETF seems to invest most of its effort at the beginning (the BOF process)
and at the end (IESG review).   Neither investment seems to be very effective. 
At the beginning, the BOF process has been called a "blood sport"; at the end,

a "death by a thousand cuts".  I had not considered the leach analogy before,
but perhaps there is something there ;)


I've always believed that WG chartering is the single most important
action the IESG takes (with significant input from the IAB),
so to me the up-front effort is absolutely justified. If we charter
an effort that is going to take several years, we are committing
a lot of resources and maybe setting a major technology direction,
way beyond the IETF community itself. So that doesn't bother
me. If we can make the process more comprehensible and clear,
so much the better.

As for the back end issue, well, we can only change that if we
get more early and ongoing review. As long as documents continue
to emerge from WGs with significant issues of clarity, interoperability,
etc, what else is going to happen? I've seen IESG review from both
sides and the middle, and it's mainly about quality control.

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-mip6-bootstrapping-split

[Brian E Carpenter]

The attached review was written for the General AD but is copied
here since the Last Call is still open. (And FYI, Jari is
holding a precautionary DISCUSS until the Last Call ends.)

Brian

 Original Message 
Subject: Gen-ART review of draft-ietf-mip6-bootstrapping-split-05.txt
Date: Tue, 19 Jun 2007 09:10:56 +0200
From: Brian E Carpenter <[EMAIL PROTECTED]>
To: General Area Review Team <[EMAIL PROTECTED]>
CC: Jari Arkko <[EMAIL PROTECTED]>,  [EMAIL PROTECTED],  [EMAIL PROTECTED],  [EMAIL PROTECTED], 
Basavaraj Patil <[EMAIL PROTECTED]>


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mip6-bootstrapping-split-05.txt
Reviewer: Brian Carpenter
Review Date:  19 June 2007
IESG Telechat date: 21 June 2007

Summary: This draft is in good shape but has some open issues
around underdefined interoperability. It misuses the term
'anycast'.

Comments:

Substantive:


The draft is generally very clear if one accepts the underlying 
model of a split between the Mobility Service Authorizer (MSA)
and Mobility Service Provider (MSP). However I have a concern
that under-specification of MSA/MSP interaction and some details 
of MN/HA interaction may lead to interop issues and therefore
encourage the formation of walled gardens, which is the last 
thing the Internet needs in mobile service. Also the term 'anycast'
is misused. Details follow:

> 3.  Split scenario
...
>If, instead, a PKI is used, the Mobile Node and HA exchange
>certificates and there is no AAA server involved [10].

It is not indicated here or later how this is determined. How, in
an arbitrary deployment, does a MN know whether the AAA or PKI
model is used? Is a MN implementer supposed to code both solutions?

> 4.  Components of the solution
...
>An optional part of bootstrapping involves providing a way for the
>Mobile Node to have its FQDN updated in the DNS with a dynamically
>assigned home address.

This turns out to assume that dynamic DNS updates are deployed. I wonder
whether this is a realistic assumption.

> 5.1.2.  DNS lookup by service name
...
>   ...If the Home Agent of choice does not
>   respond for some reason or the IKEv2 authentication fails, the Mobile
>   Node SHOULD try other Home Agents on the list.

This is underspecified - what is the timeout for non-response? 
Also is the MN supposed to loop, or to try each HA once only?

> 5.1.3.  Anycast Address for Home Agent Assignment

There is a serious problem with the way this document uses the
term "anycast address" - see details under section 5.2.1.

> 5.2.  IPsec Security Associations setup
...
> ...  Choice of an IKEv2 peer
>authentication method depends on the deployment.  

Again: that is underspecified. Does an MN implementer have
to implement both, and how does the MN know which one to use?

> 5.2.1.  IKEv2 Transaction with anycast Home Agent assignment
...
>...The Mobile Node sends the IKE_SA_INIT request to the
>anycast address.  The node which has the anycast address assigned to
>one of its network interfaces...

That is not IPv6 anycast. The definition of IPv6 anycast addresses is
quite clear (RFC 4291):

Anycast:   An identifier for a set of interfaces (typically
   belonging to different nodes).  A packet sent to an
   anycast address is delivered to one of the interfaces
   identified by that address (the "nearest" one, according
   to the routing protocols' measure of distance).

In other words, an anycast HA implementation would assign
the anycast address to *all* the HAs and the first one to
respond would "win".

What is described in the current draft is a perfectly reasonable
redirect mechanism for load sharing (albeit with a single point
of failure) but it is *not* IPv6 anycast. It would be anycast
if *any* of the HAs could respond with the redirect.

Either the design should be modified to do this, or the word
"anycast" should be dropped from the description.

I don't know IKEv2 well enough to find fault with the cookie
mechanism for implementing a secure redirect. Even though
it's a bit of a hack, it seems to work. I note that RFC 4306
does not use the term '"under attack" cookie'.

...
>The use of anycast address as specified above requires the
>implementation of anycast forwarding in such a way that the Home
>Agent can distinguish between an IKE_SA_INIT forwarded through an
>anycast address and one sent directly from the Mobile Node.  One
>possible mechanism is to use IP-in-ip t

Re: Role of IANA in approving assignments

[Brian E Carpenter]

On 2007-06-17 14:41, Harald Alvestrand wrote:

Robert Elz wrote:

And in this case, this is exactly the point.   IANA is the
INTERNET Assigned Numbers Authority, not the IETF Assigned Numbers
Authority - and the code points it assigns and the registries it
maintains are used by the Internet as a whole, not just that part of
it that participates in the IETF.

In my opinion: No. There's no magic in names.

The IANA is a function carried out by a department of ICANN. It has 
inherited the name from the work done by Jon Postel since the time when 
the Internet was small enough that all the users knew each other by 
name. But there is no magic in the name that makes this department have 
any more credibility than any other group that performs functions.


We, as the IETF, whose mission it is to "make the Internet work better", 
need to look at what the function we want to have performed is, and 
whether the current entity is the best one to perform the function we 
want performed. 


And we did, which is why there is an MoU and an SLA in place between
the IETF and IANA, both of which were open for debate here before
they were concluded.

 Brian

Others have to perform the same evaluation when 
entrusting their registration functions to this entity.


The name is just a name.

 Harald


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

On Experts [Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)]

[Brian E Carpenter]

On 2007-06-15 18:04, Michael Thomas wrote:

Thomas Narten wrote:


If a respected security expert (one who has reviewed many documents,
contributed significantly to WG efforts, etc.) comes to a WG and says
"there is a problem here", but 5 WG members stand up and say "I
disagree and don't see a problem", do you really expect the security
expert's opinion to be given strictly equal weight and to just be
overruled since 5 voices are greater than 1?
  

Context matters here. I've seen situations where the so-called "expert"
is unable to articulate the problem, is rocking a personal hobby
horse of theirs, is expressing a general philosophic point without much
attention to the actual problem (see "unable to articulate"). Etc. Also:
it may just be me, but this gradual creep toward "experts" having a
named, and different status is bothersome ("expert review"). It sweeps
under the rug that this is really a continuum of cluefulness, experience,
as well as frankly political considerations, some of which are more
odious than others.


Mike, just to try clarify the "expert review" issue. That term comes
up specifically for IANA assignments that are controlled more than
First Come First Served and less than RFC Required. There's a full
discussion in draft-narten-iana-considerations-rfc2434bis but my
short version is: we can't expect IANA to have in-house expertise
for every registry, and we don't want an IETF debate about every
relatively routine assignment. Having designated experts seems to
be the only reasonable and scaleable solution.

I prefer personally to use a term like "specialist" for review
of drafts, or "generalist" in the case of Gen-ART reviews. You
can be a specialist without being an expert :-)

 Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

On 2007-06-15 10:25, [EMAIL PROTECTED] wrote:

Thomas Narten wrote:


If the above text were in effect today, would it be sufficient to
cover the situation at issue here? (Now would be an excellent time
to consider updates/clarifications to the above text.)


I don't think so. The text allows IESG to override the allocation
procedures when they judge there is "strong IETF consensus" to do 
so.


In the situation at issue here: IMHO the main question is whether 
we have rough consensus that this particular draft should be 
published as non-Standards Track RFC.


If the IESG thinks we have this consensus, they would just approve 
the document, and the override procedure would not be needed. 


Yes it would, if registration normally requires Standards Action.

If 
the IESG thinks there is no consensus (or it's too rough), the 
override rule wouldn't apply.


So while I think the override rule might be valuable in some
cases, it doesn't seem to help here. 


I think another aspect is whether the IETF chooses to give IANA
some discretion to document usage which is widespread, but not
covered by any IETF document or procedure. It may not be appropriate
to expect the IESG to spend time on every case, or even to look for
consensus when what is being documented is simply a fact of life.
As a friend of mine used to say, you can't vote on facts.

  Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IANA registration constraints

[Brian E Carpenter]

On 2007-06-13 16:37, Jari Arkko wrote:

Phillip,


My personal view is that we should develop an Internet architecture that allows 
an infinite number of new protocols to be deployed without consumption of 
scarce resources, i.e. port numbers of DNS RRs.

...

So in summary, the IAB should be charged with identifying the set of finite 
resources that IANA assigns and propose an Internet architecture in which 
deployment of new application layer protocols does not cause any of the finite 
resources to be depleted.
  


I'm definitely in favor of improving the situation. And for applications
protocols this is probably an easier problem to begin with. And as
I said in the previous e-mail, as far as I know, most new work uses
field sizes and types that have less scarcity.

However, the Internet runs to a large extent on protocols that were
designed decades ago, and some of those protocols have number
spaces that  are very finite. I don't want to run out of protocol
numbers, DHCP message types, etc.


Exactly. There are very tight namespaces where we need to apply pretty
strict rules to avoid hitting a brick wall, but nobody can disagree that
we should design to avoid creating new brick walls.

But in the namespaces where there is no brick wall, there are nevertheless
reasons to be careful. I'd suggest that people should not only look
at the text of 2434bis, but also at RFC 4775 and at
draft-carpenter-extension-recs-02.txt. Comments on the latter are very
welcome.

I don't believe we should do anything that can be interpreted as condoning
misappropriation of IANA-assigned values. But I do agree with John Klensin
that when something is in actual use, that fact should be recognized,
and registered with a factual comment. That helps interoperability even
if it offends our formalities.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Un-expiring procedural documents

[Brian E Carpenter]

On 2007-06-13 17:18, Paul Hoffman wrote:

At 2:11 PM +0300 6/13/07, Jari Arkko wrote:
Yes -- but for clarification to others (I know you are aware of this), 
the

criteria are in active use by the IESG and often referred to when we
talk about some AD's discusses. The document was originally an
I-D (now expired), but is available from:


Isn't this what the ION series is for?


Sure, but someone has to do the work to IONize each such document.
That's why I built the ad hoc list still to be found at
http://www.ietf.org/u/ietfchair/opNotes.html

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)

[Brian E Carpenter]

We trust the IESG not only to judge consensus but also to provide
technical mentoring and leadership. We trust the IAB not only to
arbitrate in case of disagreement about consensus but also to
provide architectural insight and leadership.

Yes, that gives them a special status. It's called 'primus inter pares'.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

John,

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.

Brian

On 2007-06-12 17:11, John C Klensin wrote:



--On Tuesday, June 12, 2007 07:11 -0700 Dave Crocker <[EMAIL PROTECTED]> 
wrote:



To obtain "IETF approval", there needs to be a sponsoring AD.
Sam explained why he feels he cannot fill that role any
longer.  Whether some other AD feels can can serve in his
stead is their individual decision.  We do not have any rules
that compel an AD to sponsor a submission.  Indeed, being able
to obtain a willing sponsor is considered part of the IETF
vetting process.

Nothing prevents the document from being submitted directly to
the RFC Editor, for publication as a non-IETF document.


That is the avenue I would prefer, but it raises another issue (which I 
think would fall into the category Eliot referred to as process>).   As Sam points out, the actual use of this as a protocol 
requires IANA registration of parameters and current procedures for TLS 
extensions and many other things require IETF consensus for such 
registrations and hence for publication of any document that specifies, 
or requests IANA registration of, such parameters.


There may be things that make this particular case special, but, for the 
general case, I have gradually come to think that model is broken.  The 
problem is that the IETF cannot _prevent_ someone from making up a 
parameter and using it, registered or not, nor can we punish someone who 
does so.  So, by preventing registration, we do little but increase the 
odds that one unregistered and unapproved extension will use the same 
parameter keywords as another, causing interoperability problems.  
Preventing publication and registration does not necessarily reduce the 
odds that the extension will be used; it merely reduces the odds that a 
system encountering that extension will be able to properly identify it 
and easily determine what it is attempting to do.


Consequently, I believe that many of the  
registration requirements should be changed to permit an alternate lower 
threshold of:


(1) There has been IETF review and discussion, but the
IETF did not conclude that the idea was wise, or even
perhaps concluded that it was a bad idea.  Note that
this is very different from "not reviewed in the
IETF".

(2) There is a reasonable basis for concluding that the

protocol has been, or is likely to be, deployed.

For that class of situation, I now believe that it should be possible to 
make an independent submission and, if the RFC Editor judges that the 
document is of adequate interest and technical and editorial quality, be 
published and the registrations made.  Of course, the document should, 
at that stage, be very clear that it is not an IETF-approved protocol 
and should ideally explain the reasons why the IETF did not approve 
it.   Similarly, the registration should be made in the interest of 
interoperability but both the "IANA Considerations" section of the 
document and the registration itself should clearly indicate that the 
registration is to prevent interoperability problems only and does not 
imply approval or endorsement.


Our pretending that a protocol extension will simply go away because we 
don't like it --or because we can't agree that we do like it-- does not 
make the Internet work better.


 john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: consensus and anonymity

[Brian E Carpenter]

On 2007-06-01 18:52, Michael Thomas wrote:
...
part. Still, I think it's a myth that these hums are *just* the sense of 
the room
and no more. They're clearly a lot more than that as it almost always 
brings

a conclusion to some point of contention, and when it's brought up again on
the list you can almost always be guaranteed a "but we decided this in 
Oslo!".


That's exactly when a good WG chair or AD *should* say: Yes, but now we have
a new technical issue that we need to analyze.

Of course, there's always scope for argument whether a an issue is really
new and really significant.

Brian



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: consensus and anonymity

[Brian E Carpenter]

Combined response:

On 2007-05-31 21:33, Spencer Dawkins wrote:
The alternative - a WG chair who tells the working group that the apparent WG consensus on the mailing list is being overruled because of anonymous objections that the WG chair cannot share with the WG, or because of private objections that the WG chair is "channeling" from a back room - would make voting seem reasonable (or, to use Mark Allman's characterization in another thread, "seem charming"). 


I have to differ. This doesn't make voting seem reasonable; it makes
secrecy seem unreasonable.

On 2007-05-31 21:40, Hallam-Baker, Phillip wrote:

If the wg chair is also on the iesg the appeals process is fatally compromised 
and littigation may be the only realistic prospect for redress.


Not at all. That is why ADs and IAB members recuse from appeals in
which they are materially concerned.

On 2007-05-31 22:08, Michael Thomas wrote:

One thing that occurs to me is that in my initial message I implicitly
felt that the room hands/hums were a more accurate assessment of
consensus than the list. I guess that I should fess up that I've always
felt that the "consensus is determined on the list" is something of a
charming myth.


I don't think people unable to travel to meetings would agree. Since our
objective is to discover technical problems with a proposed consensus,
I think it's essential to allow any netizen to raise problems. One
email technical comment pointing out a serious flaw has far more weight
than a hundred people in a room going "mmm".

On 2007-05-31 23:07, Andy Bierman wrote:

I think the inability of the IETF to make decisions in
an open, deterministic, and verifiable manner is a major flaw.
It promotes indecision and inaction.


I think the ability of some other SDOs to take go/no go decisions on
unpublished documents by a fixed deadline, based on corporate voting,
is a major flaw. It promotes superfical review and flawed documents.

On 2007-06-01 01:14, Andy Bierman wrote:

I don't understand why such a comment needs to be private.
Once the issue comes to light in the WG, it is no longer going
to be private.

You are assuming the Chair can and should be a proxy for a
WG member who wishes to remain anonymous.  I disagree. 


Why is this a problem? Again, our goal is to discover technical
flaws (or make technical improvements) in drafts. What does it
matter if someone has good reason to request anonymity and to use
the AD (or anyone else) as a proxy?

On 2007-06-01 04:09, Henning Schulzrinne wrote:

I think a fair vote requires

- a clear definition of who can vote 


Which is fundamentally impossible in the IETF.

On 2007-06-01 04:22, Lakshminath Dondeti wrote:
Can anyone point to me where it is written that voting at a meeting is 
the decision making process when rough consensus (hum or whatever) has 
been inconclusive?


Definitely, nowhere. But there is a model that has been used
where a WG agrees *by rough consensus* to accept an arbitrary decision
method when a technical rough consensus cannot be reached. Example:
http://www1.ietf.org/mail-archive/web/ietf/current/msg46040.html

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: BOF Process

[Brian E Carpenter]

On 2007-05-26 05:35, Bernard Aboba wrote:
...
In my experience, part of the issue is lack of feedback on what the next 
steps are.  


Pragmatically, I suggest helping to improve draft-narten-successful-bof

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Putting IPR on the IETF consensus proccess (was: beware of fake pills)

[Brian E Carpenter]

Legally, they're very different. What I meant was that a free software
developer can probably work reasonably comfortably with either of them.

Of coure IANAL.

Brian

On 2007-05-26 05:50, Bernard Aboba wrote:
With all due respect,  broad defensive non-assert clauses are quite 
different from RF licenses.  For an analysis of the differences, see the 
article below: 


http://www.law.uchicago.edu/files/lichtman/def-susp.pdf

Brian Carpenter said:

It's a defensive non-assert disclosure, which IMHO is equivalent to RF
for anyone who plays nicely. Actually a defensive non-assert may
indirectly *protect* a normal implementor, when you think about its
impact on a third party implementor who does try to assert a patent.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: On the IETF Consensus process

[Brian E Carpenter]

On 2007-05-26 00:46, Lakshminath Dondeti wrote:
...

Coming to the fear of retaliation issue (I guess we are talking about 
unethical behavior on part of an IESG or IAB member at this point), we 
need to find a way to fix that.  On this, we seem to be worse off than 
the outside world.  Let's take the US as an example (or we can take 
India too; I am sorry, but those are the only two countries I am 
somewhat familiar with): there are always checks and balances.  


That's exactly why we have the appeals process, the recall mechanism,
and an independent Nomcom. And speaking for myself (and probably
others) that's why more transparency is always good, as long as
it doesn't prevent the IAB and IESG being able to discuss frankly.

If you can suggest additional checks and balances, please do!

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: On the IETF Consensus process

[Brian E Carpenter]

On 2007-05-26 00:17, Lakshminath Dondeti wrote:

Hi Brian,

Glad to hear that you see the value in making the IAB reports public.  I 
think that this is something that needs to happen on an urgent basis. 
Please see inline for additional notes:


On 5/25/2007 1:39 AM, Brian E Carpenter wrote:

On 2007-05-24 20:11, Jeffrey Hutzelman wrote:



On Wednesday, May 23, 2007 06:56:10 PM -0700 Lakshminath Dondeti 
<[EMAIL PROTECTED]> wrote:


...

For instance, I had started thinking more clearly about BoF 
processes and

how a small set of people can derail a BoF process after I started this
thread.  A few vocal people at the mic and secret reports from IAB
members (conflicts of interest seem to go unnoticed) can undo months
worth of work and the proponents have to wait 4 more months to do
anything.  There is no reason it needs to be that way.


Sorry; I really want to answer this part, but I'm out of time for 
now. Perhaps I'll come back to it next week.


Well, I'll have a go. First of all, advising the IESG on WG chartering is
part of the IAB's job, and in my opinion it is the most important point
at which the IAB can actually exercise architectural influence rather 
than

just pontificating.


Sure, we need the reactive approach (architectural policing), but I 
think that the proactive aspects (architectural guidance) are also 
essential.


Yes of course - and in my experience both things happen. But the IAB is
only 13 people, so you can't expect them to be the originator of all
innovation. And the IAB tries to be proactive in various ways, not
just in the BOF process.





Secondly, some of what needs to be discussed at the post-BOF, pre-WG
stage is intrinsically private: suitability of people to be WG chairs,
questions about conflict of interest on the part of individuals who
are pushing for one or another solution, etc. I strongly defend the
IESG and IAB's right to private discussion on these points. And that
means private email.


That all sounds too political!  Most of this should be transparent. 


I'm trying to explain the things that need to be discussed in
private: personnel questions, as you say below.

What 
are people on the IESG/IAB afraid of in sharing their honest views on 
whether a particular BoF proposal is bad/ugly/good/ok?


I don't think they are. In fact I've often seen IAB members send mail
to a public list that contains the same points as their BOF report
to the IAB+IESG, except for the personnel issues. If the IAB did decide
to make the BOF reports public, they would clearly be versions
without the personnel issues.

Being recalled?  
That never happens!


But nevertheless, in my experience both the IAB and IESG are aware
that it could happen. I'm not saying that is a cure-all, but it's
a reminder that they are responsible to the community.



As to picking chairs, why is the BoF process any different than the WG 
chair picking process (interim appointments)?  The sponsoring/advising 
AD may send a call for nominations, may seek input from the community 
(some of them may be on I*, sure) and makes a decision.  He/she might 
write a blurb on why a certain person was selected too.


That could happen, but the timeline for BOFs is very tight. I don't
think there's time for such a process in reality, unless we made the
deadlines much earlier.


There is no need for any significant "private" discussion (except for 
discussion on personnel, 


That is exactly the point. Who chairs a BOF is a personnel issue.

legal and financial aspects).  Let's just say 
that I like BCP 39's Section 3.6 better than Section 3.2 of 3710.




Thirdly, IAB and IESG members could indeed have potential conflict
between their (or their employers') goals and "making the Internet
work better". That's intrinsic to everything the IAB and IESG do,
not just to BOF handling and WG chartering. That's why we have
a preference for openness whenever possible, and why we have the
appeals and (theoretical) recall mechanisms.


Having been on the nomcom, my recollection is that people say the right 
things in their questionnaires or interviews.  So, I wonder what's going 
on.


Nothing?





So, I would see value in the IAB's BOF reports being made public,
as far as their technical content goes, but on the clear
understanding that there will be private communication on sensitive
issues.


Let's start making the IAB BoF reports public!  Do we need to write a 
draft for this or does the IAB just need to start doing the right thing?


Not my department any more ;-)

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: On the IETF Consensus process

[Brian E Carpenter]

On 2007-05-24 20:11, Jeffrey Hutzelman wrote:



On Wednesday, May 23, 2007 06:56:10 PM -0700 Lakshminath Dondeti 
<[EMAIL PROTECTED]> wrote:


...


For instance, I had started thinking more clearly about BoF processes and
how a small set of people can derail a BoF process after I started this
thread.  A few vocal people at the mic and secret reports from IAB
members (conflicts of interest seem to go unnoticed) can undo months
worth of work and the proponents have to wait 4 more months to do
anything.  There is no reason it needs to be that way.


Sorry; I really want to answer this part, but I'm out of time for now. 
Perhaps I'll come back to it next week.


Well, I'll have a go. First of all, advising the IESG on WG chartering is
part of the IAB's job, and in my opinion it is the most important point
at which the IAB can actually exercise architectural influence rather than
just pontificating.

Secondly, some of what needs to be discussed at the post-BOF, pre-WG
stage is intrinsically private: suitability of people to be WG chairs,
questions about conflict of interest on the part of individuals who
are pushing for one or another solution, etc. I strongly defend the
IESG and IAB's right to private discussion on these points. And that
means private email.

Thirdly, IAB and IESG members could indeed have potential conflict
between their (or their employers') goals and "making the Internet
work better". That's intrinsic to everything the IAB and IESG do,
not just to BOF handling and WG chartering. That's why we have
a preference for openness whenever possible, and why we have the
appeals and (theoretical) recall mechanisms.

So, I would see value in the IAB's BOF reports being made public,
as far as their technical content goes, but on the clear
understanding that there will be private communication on sensitive
issues.

 Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Putting IPR on IPFIX while the target of IPFIX is to in effect open NetFlow (Was: [IPFIX] Implementation Guidelines // SCTP)

[Brian E Carpenter]

On 2007-05-23 14:19, Jeroen Massar wrote:
...

 Alternatively, directly look up 
http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt



(The above long formatted lines are not mine, 72 is a nice limit FYI)

Sorry to be blunt, but what exactly is the point again of 'opening up
NetFlow' if there is going to be IPR stuff being smacked upon IPFIX and
thus encumbering it?


It's a defensive non-assert disclosure, which IMHO is equivalent to RF
for anyone who plays nicely. Actually a defensive non-assert may
indirectly *protect* a normal implementor, when you think about its
impact on a third party implementor who does try to assert a patent.

   Brian (IMHO, YMMV, etc.)

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: On the IETF Consensus process

[Brian E Carpenter]

On 2007-05-22 23:20, Lakshminath Dondeti wrote:
I am beginning to wonder about the IETF consensus processes and so 
figured I will ask for advice on this list.  First, a summary of some of 
my observations over the past few months (I have real examples of these, 
but we don't quite need to get into those):


1. Some people (WG chairs) seem to (want to) ask for consensus on 
everything and that too many times:
 1a.  Ask for consensus on whether to adopt a document as a WG 
item,
whether something is/should 
be in the charter

who should be an editor
should the WG meet


Those are all separate questions. What is the harm in a chair wanting
to test consensus, even on matters where the chair has power of decision?


 1c. Ask again and again


That certainly happens when the reply to a question is silence, or just
a couple of messages, or irrelevant replies. A chair who really needs
to know whether a draft has WG support, for example, sometimes needs
to ask several times to hear from anyone except the authors. Again,
what is the harm?

   2. Some people do it in multiple settings and in many different 
combinations

2a. Ask on the mailing list
2b. Ask at a f2f meeting (sometimes, after having asked a 
question on the mailing list)
2c. And sometimes ask again on the mailing list (sometimes, 
after 2a even)




Yes. Results can be ambiguous and people can change their minds after
hearing additional arguments. As I understand it, the philosophy is to
get the best possible technical spec, not to meet an arbitrary deadline.
And that can mean looping over the same items.

   3. Some people ask questions at a face to face meeting and declare 
consensus one way or another


You can declare consensus of the people in the room. But as you say,
the rule is that the consensus that counts is the consensus on the list.
That's exactly why you will see the sequence 2a 2b 2c; 2c is to confirm
the consensus in the room reached in 2b. The discussion in 2b may change
some opinions given in 2a.



 From 2418 and 4677, my understanding has been that

  i) there are certain things such as appointing editors which are up to 
the chairs' discretion and appointing chairs which is up to the ADs' 
discretion (they may seek open or selective input, but are not 
necessarily required to do so).


Exactly. So what is the problem with a chair choosing to seek WG input?

 ii) asking for consensus once is sufficient and the process may be 
repeated only if things were unclear.


And in my experience, they are often unclear, and new technical
issues are often raised.

 iii) asking a question on the mailing list is sufficient to declare 
consensus; if opinions were sought at a face to face meeting, the 
chair/AD must ask on the mailing list before declaring consensus.


Correct.

Yet I see ADs declaring consensus after getting the sense of the room at 
a face to face meeting 


But they must always add "to be confirmed on the list" and must always
do so - if they don't, it's a clear process violation and can be
appealed.

and so I am curious whether our process documents 
are out of date or whether I am reading them out of context.


They are out of date on many details but IMHO not on these
fundamentals.

Brian
--
NEW: Preferred email for non-IBM matters: [EMAIL PROTECTED]

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Brian E Carpenter]

On 2007-05-22 07:51, Philip Guenther wrote:

On Mon, 21 May 2007, Jeffrey Hutzelman wrote:
...
It seems to me that specs should _not_ explicitly specify which TLS 
version to support, and should instead refer to an STD number.  
Applications don't generally specify which verisons of IP or TCP to 
use, and TLS is at a similar level of abstraction -- except that the 
situation is not as painful, because using a different version of IP 
means you have to use completely different names, whereas using a 
different version of TLS does not.


We expect application protocols that require TLS to specify a mandatory- 
-to-implement ciphersuite to guarantee interoperability between clients 
and servers.  How is the TLS version any different?  A client that only 
supports TLS 1.0 will fail at handshake time if the server only supports 
TLS 1.1.  Therefore, if interoperability is the goal, requiring support 
for a specific version is necessary.


Since as you point out, TLS has version negotiation, don't you mean
"support for at least one specific version is necessary"? And presumably
that would be a version whose security is believed to be minimally
adequate, with all earlier versions being forbidden. For example
  Implementations SHOULD support TLS 1.1 or later, MUST support TLS 1.0,
  MAY support SSLv3, and MUST NOT support SSLv2 or earlier.

  Brian
--
NEW: Preferred email for non-IBM matters: [EMAIL PROTECTED]

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC

[Brian E Carpenter]

On 2007-05-21 12:47, Jari Arkko wrote:

Brian,


Section 8 states


   Applications MUST not set contradictory flags at the same time.

I think the document should specify what the API must do if
contradictory flags are set. That would be the normative MUST, not
the above statement of the obvious.


Thanks for your review, Brian!

I agree with the principle that you state above. However,
the document does have a definition of contradictory
flags (Section 2) and explicitly describes what the API
must do when getting them (Section 6) i.e., causes
error EINVAL. Or EAI_BADEXTFLAGS for getaddrinfo
(Section 7).


Ah, sorry, I'd missed that.



I do agree though that there's something wrong in the
text in Section 10 about application requirements.
Perhaps s/MUST not/should not/. This may apply to
some other text in Section 10, too.


Yes, I think it is strange to use the normative words
in this way.

Brian

--
NEW: Preferred email for non-IBM matters: [EMAIL PROTECTED]

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC

[Brian E Carpenter]

Section 8 states


   Applications MUST not set contradictory flags at the same time.


I think the document should specify what the API must do if
contradictory flags are set. That would be the normative MUST, not
the above statement of the obvious.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?

[Brian E Carpenter]

On 2007-05-14 16:08, Shane Kerr wrote:

Brian,

On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote:

On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote:

The RIRs don't depend on IETF at all, they can define global
policies for things that the IETF failed to complete if that's the
case. IANA can be instructed the same by the RIRs (which a global
policy) than by the IETF itself with an RFC.

Not quite. The RIRs have authority delegated to them by IANA, and
IANA operates under the terms of its MoU and SLA with the IETF. So
the RIRs' scope is to set and implement policy within their
delegated authority, which itself has to be within the terms of the
IANA MoU and SLA.


The RIRs authority comes from their communities, not from IANA.
That's what "bottom-up" means.


We're both right. It works because there is a wide consensus to both
listen to the community and respect the mechanisms in place.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Can the RIRs bypass the IETF and do their own thing?

[Brian E Carpenter]

On 2007-05-11 16:14, Fred Baker wrote:
...
One technical question I would ask. What does a "Central Authority" and 
"IANA Assignment" have to do with a "Local" address of any type? It 
seems in context that the major issue is an address prefix that is not 
advertised to neighboring ISPs and can be generally configured to be 
refused if offered by a neighboring ISP, in the same way that an RFC 
1918 address is not advertised and is generally refused between IPv4 
networks. In any draft on this topic, regardless of where it is 
discussed, if central assignment is in view, the reason for having such 
assignment should be clearly stated.


Fred, the point is that ULAs should be unambiguous, so that if they
happen to meet (e.g. via a VPN, or following a merge of two previously
separate networks) there is no collision. Currently ULAs include
a pseudo-random prefix, which leaves open a theoretical possibility
of collision. Centrally-allocated ULAs would not have this issue.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Can the RIRs bypass the IETF and do their own thing?

[Brian E Carpenter]

On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote:

I've already indicated this in previous occasions, but may be not in ppml
...

We are proceeding in parallel, with the ID and the PDP at the same time.
Nothing in the PDP precludes doing so.

The RIRs don't depend on IETF at all, they can define global policies for
things that the IETF failed to complete if that's the case. IANA can be
instructed the same by the RIRs (which a global policy) than by the IETF
itself with an RFC.


Not quite. The RIRs have authority delegated to them by IANA, and IANA
operates under the terms of its MoU and SLA with the IETF. So the RIRs'
scope is to set and implement policy within their delegated authority,
which itself has to be within the terms of the IANA MoU and SLA.

In this case, I would check out section 4.3 of RFC 2860, especially
the clause (b) in the second paragraph. It's clear to me that centrally-
allocated ULAs are in IETF scope under that clause.

That being said, there's no conceivable problem with a draft being
developed by any set of people that want to do so, and the RIR people
are obviously strongly motivated to do so in this case. (Personally,
I see little need for it, since the existing pseudo-random ULAs
are good enough for any practical purpose, but that is a discussion
we can have in the IETF once there is a draft to discuss.)

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IAOC Communications Plan: Review Requested

[Brian E Carpenter]

I don't see any reference to the reports to Plenary at each IETF meeting
(both the short report presented on stage and the longer reports posted
to the wiki).

I liked it at the beginning when the IAOC also put out a short monthly
email to the community. Even though the pace of events may be less now,
a short email flagging any news is a lot more convenient than remembering
to look at minutes and reports on the wiki.

Brian

On 2007-05-02 19:09, Ray Pelletier wrote:

All;

The IAOC recognizes its responsibility to oversee IASA on behalf of the 
IETF community in a transparent manner and to that end publishes this 
Draft Communications Plan for community review before its adoption.


The Plan can be found at 
http://www1.tools.ietf.org/group/iaoc/wiki/CommsPlan
It is in pdf and doc/xls formats and consists of two documents, a draft 
plan and a matrix.


This draft Communications Plan identifies the information to be 
communicated to the community, the desired frequency and the mode of 
those communications.


RFC 4071 provides general and specific guidance to the IAOC and IAD 
regarding their responsibility to ensure transparency in the operation 
of the IASA. This Plan implements the requirements of RFC 4071 and 
provides additional reports to the community to enhance its visibility 
into the operation of the IASA.


Section C defines Confidential Information.

Section D identifies the communications channels the IAOC will employ to 
publish the report.


Section E defines the reports.

The Communications Plan Matrix provides the details of what, when and 
where of the reports to the community, as well as specifying the RFC 
4071 reference where applicable.


Feedback on this draft plan is welcome. The next iteration of the Plan 
will consider feedback received through 16 May 2007. Reviewing the 
MATRIX may be a good starting point for the review. Feedback should be 
addressed to iad at ietf.org.


Thanks for the assistance.

Ray Pelletier
IAD

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ADs speaking for "their" WGs

[Brian E Carpenter]

On 2007-04-20 23:58, Theodore Tso wrote:

On Fri, Apr 20, 2007 at 04:56:38PM -0400, Jeffrey I. Schiller wrote:

But the more serious case involved IPSEC. The situation was thus:

~20 people  for one proposal.
~20 people  for a different proposal
~150 people for "someone please decide so we can go off and
 implement!"

So I read the consensus as "We want this solved." I then asked the
authors of the two proposals if they could come to consensus by
September 1, 1996 (this was in March of 1996). They said they would
try. On August 29th I received a phone call telling me that they tried,
but could not agree.

So I decided.

I chose one of the proposals and wrote up my decision and sent it to the
WG list. I outlined my decision criteria, and how I viewed each proposal
against the criteria, finally offering to publish the "losing" proposal
as informational documents.

My one regret is that I didn't publish my decision as an RFC. Just
didn't think about it. I may dig it out of my e-mail archives and
publish it at some point (with some additional historic background) as a
historical RFC. The more time I get to refer to it, the more it makes
sense to publish it.


For people who are interested in reading Jeff's writeup, it can be
found here:   (nothing ever disappears from the internet :-)

http://www.sandelman.ottawa.on.ca/ipsec/1996/09/msg00096.html


Thanks Jeff and Ted.

In fact, Jeff's approach and his message were very carefully constructed:

"After September 1, if the working group could not decide upon a course
of action, then I would step in as Security Area Director and propose
one myself.
...
I formally recommend, as Security Area Director, that the charter for
the IPSEC working group be amended.
...
Proposed New Charter..."

Quoting myself:

 Ah, but if the WG *agrees* to accept the AD's decision, that's OK.
 The rules in 2418 certainly allow an AD to ask a stuck WG "Will you
 let me decide?". That's very different from deciding unilaterally.


I agree with what I think I hear Jeff saying: ADs should be free to act
decisively when a WG is indecisive, as long as they remain respectful of
the overall goals of openness and fairness.

   Brian



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ADs speaking for "their" WGs

[Brian E Carpenter]

On 2007-04-20 14:44, Scott W Brim wrote:

On 04/20/2007 08:35 AM, Brian E Carpenter wrote:

It seems fairly clear in RFC 2418 section 6.1:

  "The Chair has the responsibility and the authority to make decisions,
   on behalf of the working group, regarding all matters of working
   group process and staffing, in conformance with the rules of the
   IETF.  The AD has the authority and the responsibility to assist in
   making those decisions at the request of the Chair or when
   circumstances warrant such an intervention."

So the AD *does* have authority *when circumstances warrant*, but
only on matters of process and staffing. I'm sure Jeff Schiller didn't
mean any more than that - this rule doesn't allow an AD to take
technical decisions unilaterally, but does allow an AD to make a
consensus call if for some reason the WG Chairs can't do so. (And
all subject to the regular appeal process, of course.)


My recollection is that Jeff made a technical decision and announced
it, because everyone agreed the process was deadlocked.  I don't
recall that he ever "took over" for a WG chair, but there was
agreement that the WG was stuck and a decision was required.



Ah, but if the WG *agrees* to accept the AD's decision, that's OK.
The rules in 2418 certainly allow an AD to ask a stuck WG "Will you let
me decide?". That's very different from deciding unilaterally.

Sorry to be picky but I think this distinction matters.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[Brian E Carpenter]

On 2007-04-20 09:21, Hannes Tschofenig wrote:
DHCP is not a great choice in a mobile environment and also not when it 
comes to more complex location representations.


Why can't a mobile system have a locally valid DHCP record (+/- the length
of a wireless link)? For that matter, why couldn't a DHCP server have
real-time triangulation data, if it exists at all?

Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 
together?

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ADs speaking for "their" WGs

[Brian E Carpenter]

On 2007-04-20 12:07, Frank Ellermann wrote:

Spencer Dawkins wrote:


- what we tell the WG chairs is that ADs have the power to make a decision
for the working group, in order to break a deadlock. Jeff Schiller (one of
the ADs who did the WG chair training for several years) was very clear
that an AD can say, "if you guys don't make a decision by date X, I'll make
a decision for you". If this is not part of the community understanding,
someone should be telling the WG chairs and ADs what the community
understanding is.


This is not how I understood it.


It seems fairly clear in RFC 2418 section 6.1:

  "The Chair has the responsibility and the authority to make decisions,
   on behalf of the working group, regarding all matters of working
   group process and staffing, in conformance with the rules of the
   IETF.  The AD has the authority and the responsibility to assist in
   making those decisions at the request of the Chair or when
   circumstances warrant such an intervention."

So the AD *does* have authority *when circumstances warrant*, but
only on matters of process and staffing. I'm sure Jeff Schiller didn't
mean any more than that - this rule doesn't allow an AD to take
technical decisions unilaterally, but does allow an AD to make a
consensus call if for some reason the WG Chairs can't do so. (And
all subject to the regular appeal process, of course.)


The ADs can appoint new WG Chairs if
they're unhappy with the old Chairs, they're not forced to accept one of
the Chairs as document shepherd, and there is (or was) a potential dead
loop where the reaponsible AD can say "forever" that (s)he doesn't like
a WG draft because they're unfortunately forced to vote YES otherwise.

But all that doesn't cover "ADs speaking _directly_ for a WG" wrt WG
drafts, this would remove the first step in the appeal procedure for WGs.
Please correct me if I got it wrong.  


Speaking for? That would seem strange, even as an interpretation
of "when circumstances warrant such an intervention". But the quote above
does seem to allow an AD to take over for a WG chair as far as running
the discussion is concerned, exceptionally. And yes, that does make the
first two stages of the appeal process (appeal to WG Chair and to AD)
rather empty.


Likely the rules for liaisons are
a bit more convoluted, and the rules for WG termination are in RFC 2418
no matter what ION 3710 says.


- We have been encouraging greater separation of roles (an extreme case
of non-separated roles is a document editor who is also the working group
chair, the document shepherd, and the responsible AD for the working group).



We've been saying that having ADs chair WGs in their own area is not a good
thing. We've been saying that having WG chairs edit major documents in their
own area is not a good thing. We may want to provide guidance that having
ADs chair WG meetings in their own area, especially where there is no other
person acting as chair, is not a good thing, and that the ADs really need
to find someone else who is willing to chair the meeting, and who is not
involved as the next step on the appeals ladder.


Yes.  OTOH if an important author of drafts in a WG volunteers to be an
AD and gets the job it's ugly if that would force them to give up their
I-Ds.  All areas (excl. "gen") have two ADs, that offers some leaway.


That's where recusals come from. And the General AD is at liberty to
find another AD to sponsor his or her BOFs or drafts. I did that.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68

[Brian E Carpenter]

I want to make three peripheral comments.

1. I congratulate the ADs for bringing this to the general list.
If we habitually resolve such difficulties openly, we strengthen
the IETF going forward.

2. I think we have a general problem of assuming that issues
"decided" in the meeting room and "approved" on the mailing list
by lack of complaint at the draft minutes have in fact gained
rough consensus. I'm very glad that GEOPRIV isn't assuming
that, and IMHO all WGs should copy.

3. It's aggravating when meetings get rescheduled on site, but we've
been warning people for a couple of years that "IETF Meetings
start Monday morning and run through Friday lunchtime, with late
scheduling changes." Those last 4 words mean what they say, after all.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Brian E Carpenter]

Ted,


Well, if IPR owners don't actually care, why are they asking people to
send a postcard?  It would seem to be an unnecessary administrative
burden for the IPR owners, yes?


My assumption is that they care if the party that fails to send
a postcard is one of their competitors. That's what the defensive
clauses in these licenses are all about, afaics.

...

Disclaimer: These are my own personal opinions and not necessarily the
opinions of my employer; I'm not important enough to affect the
opinions of my employer.  :-)


Ditto. (Full disclosure: Ted and I have the same employer, but
we're allowed to disagree :-)

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Brian E Carpenter]

On 2007-04-11 11:34, Arnt Gulbrandsen wrote:

Just one comment:

Brian E Carpenter writes:

On 2007-04-11 10:08, Simon Josefsson wrote:
   What typically happens in practice, among good-faith
practitioners, is that there won't be any GPL (or Apache, or
Mozilla, or ...) implementation of the patented technology atall, 
because the necessary rights cannot be acquired.


Doesn't that sound like a bug in the OSS licenses to you, assuming the 
desired result is to make the Internet work better?


In this kind of situation, what would _you_ choose?

[ ] Apply for an IPR license/sign an NDA/do other paperwork
[ ] Violate someone's something
[ ] Go do something else

My choice tends to be the last, because my goal is generally not to 
implement some specific technology, it is to increase people's happiness 
and productivity. I can do that by implementing whatever Mark has 
patented. Or in any of ten thousand other ways. See?


[X] Use a different OSS license that doesn't have this perceived problem.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Brian E Carpenter]

Simon,


4.3.  Example License Text

   Here is a simplistic patent license that would grant third parties
   the necessary rights in order to use it in free software.


   X grants a worldwide, non-exclusive, fully-paid,
   perpetual, royaltee-free patent license to everyone for
   any purpose.

   [XXX: Most likely, this section will be heavily modified based on
   feedback from the community.]


As you certainly realise, this isn't going to happen. I am not speaking
for any particular company, and certainly not for the one that pays me,
but it's clear that no company in today's IT market and today's legal
environment could make such a grant. Any RF license is going to come with
conditions that protect the IPR owner in certain ways.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Brian E Carpenter]

On 2007-04-11 10:08, Simon Josefsson wrote:

Brian E Carpenter <[EMAIL PROTECTED]> writes:


Simon,

Can you identify any instance of a non-profit GPL implementor or
distributor being sued for not having "sent a postcard" for the
style of RF license you are objecting to?


Brian, two responses:

1) You seem to assume that GPL implementers would violate the patent
   license by redistributing their code without sending a postcard.
   In order words, your question assumes and implies bad-faith amongst
   GPL implementers.


Not specifically. My question is a practical one. People who receive
open source code, tweak it, and install it may often be completely
unaware that they should be asking for a license. Do we have any
practical evidence that IPR owners actually care?


   What typically happens in practice, among good-faith practitioners,
   is that there won't be any GPL (or Apache, or Mozilla, or ...)
   implementation of the patented technology at all, because the
   necessary rights cannot be acquired.


Doesn't that sound like a bug in the OSS licenses to you, assuming the
desired result is to make the Internet work better?



1) I don't believe this is a 'send a postcard' license.  If you read
   Mark's patent license, it starts with:

   "Upon request, RedPhone Security will ...

   I interpret this to mean that unless RedPhone responds to your
   requests, you have not received any rights.  Is this incorrect?


I'm assuming you will get a postcard in reply, certainly.


There are examples where companies won't respond to requests for these
type of RF patent licenses.


The phrase you quote doesn't allow for that.


A recent example that came to mind was
related to the BOCU patent by IBM:

http://permalink.gmane.org/gmane.text.unicode.devel/23256


I won't respond here on that specific issue.



A different problem is if the patent is owned by a small company, and
the company goes away.


Normally the patent will fall into the hands of whoever strips
the assets. That's why a carefully constructed perpetual RF
license is needed, in any case.


Still, I'm not sure even a "send-a-postcard" patent license would be
compatible with free software licenses.  Sending the postcard appear
to be an additional requirement, something that some free software
licenses explicitly forbid.


I think that is a bug in the OSS licenses. Whatever you or I may think
of patent law, it isn't going away, and the OSS licenses need to deal
with it realistically IMHO.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Brian E Carpenter]

Simon,

Can you identify any instance of a non-profit GPL implementor or
distributor being sued for not having "sent a postcard" for the
style of RF license you are objecting to?

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: In support of symbolic references

[Brian E Carpenter]

On 2007-04-06 08:12, Jari Arkko wrote:

Simon,


Maybe we can lobby for it to become the default.

+1

(I think it would be the right default, even if I agree with John
Klensin's concern.)


Putting symrefs into all the xml2rfc templates would not be a
bad idea. If you want to suggest a change in the default,
writing to [EMAIL PROTECTED] is a good first move.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Brian E Carpenter]

On 2007-03-31 17:15, Eliot Lear wrote:

Jeff,
As for informational vs an independent submission, I think there is a 
factor to be considered.  It seems to me that an informational IETF 
document is a fine way to say "this is a good idea, and we think this 
is the right way to do FOO, but we can't actually recommend it (for 
whatever reason)".  For example, we have at least one document that 
defines the use of elliptic curve cryptography with one of our 
protocols, which is informational because the working group that 
produced it didn't feel they could recommend it as a standard due to 
the hairy IPR issues surrounding that technology.


Most people outside of this organization can't tell the difference 
between a standard and an informational document.  They simply look at 
the label "RFC" and are done.  And now you are trying to cut the line 
even thinner?


I think Jeff is trying to leave the line exactly where it is: the WG
(or the IETF if there is no WG) decides case by case, within the
envelope first defined by RFC 2026 and confirmed by RFC 3668 and 3979.

Personally I prefer this to any doctrinaire rules or to reliance on
precedent.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: RFC certification organization...

[Brian E Carpenter]

My personal opinion is that IETF would be taking a large risk
by doing anything like this. Certification carries serious
legal implications and therefore creates serious potential
legal risks for the certifier. That needs a completely different
type of organization than the IETF. I think we should leave this
to independent labs and industry groups. See the IPv6 Ready Logo
for example (http://www.ipv6ready.org/).

   Brian

On 2007-03-25 15:02, Stjepan Gros wrote:

Hi to all,

At the SAAG meeting on Friday question has been raised about some
provider of mail server software that violates certain rfcs. I don't
know which one, but this is not important. Also, on the RRG meeting in
saturday a provider has been mentioned that deaggregates it's network
because of "security" gains. Probably there are other, not so drastic,
examples of abuse of the work done by IETF.

All that made me question myself, why there is no something like WiFi
alliance that certifies products to be compliant with RFC's? This
organization (or whatever) can also "certify" ISPs to comply with best
practices etc. something like ISO does with ISO9001. It could also
prohibit use of IETF sign and/or compliance claims in cases of (severe)
violations. Finally, the money earned could be fed to ISOC, and to the
IETF for it's expenses.

Maybe topic has been discussed already on this list and/or maybe it's
pointless and/or maybe it's for some other list, but I had to try
anyway... So, please be gentle. :)

Stjepan Gros



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Identifying meeting attendees

[Brian E Carpenter]

"Who else is here from Nokia?"


The final version in the Proceedings does have affiliations:
http://www3.ietf.org/proceedings/06nov/index.html
but I agree that is a bit late for finding people on-site.


Taking this one step further, perhaps we could get the ICANNwiki folks
to create a photo library to enable us to find other attendees more 
easily:


http://icannwiki.org/Ole_Jacobsen


Adding a voluntary photo upload somehow would be a nice-to-have, but
if it was still my call, I'd put it lower than many other missing tools.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Already Last-Called downrefs

[Brian E Carpenter]

On 2007-03-14 15:17, Pekka Savola wrote:

On Wed, 14 Mar 2007, Brian E Carpenter wrote:

Just to confirm: 2818 has already been "downrefed" so it can be used in
this way without further formality.

http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry


There appear to have been two kinds of Last Calls:
 1) Last Call for document X which also last calls that document's 
downrefs, and
 2) Separate Last Call about downrefs to document Y (rare, see 31 Jan 
2007 example below)


2) is a special case of 1) in which the downref was initially
overlooked but was detected during the initial Last Call.



Which one(s) are you referring to?

If 1), there seems to be an assumption that if document X downrefs 
document Y, and that downref is last-called, there is no need to Last 
Call any downref to document Y.


There is no text in the Last Call message to suggests the downref should 
be considered in a 'global' sense (more like 2) above), instead of in 
the context of the referencing document.


No, that text is in RFC 3967.


I certainly wouldn't go as far as to say that if it's OK for 
draft-dusseault-caldav to use RFC2818 in a normative sense, it would 
automatically make it OK in every other protocol as well.


RFC 3967 says:
=
   Once a specific down reference to a particular document has been
   accepted by the community (e.g., has been mentioned in several Last
   Calls), an Area Director may waive subsequent notices in the Last
   Call of down references to it.  This should only occur when the same
   document (and version) are being referenced and when the AD believes
   that the document's use is an accepted part of the community's
   understanding of the relevant technical area.  For example, the use
   of MD5 [RFC1321] and HMAC [RFC2104] is well known among
   cryptographers.
=

And I'm not sure if those requirements have been fulfilled yet. Am I 
missing something?


The IESG is working on the basis that those requirements have been
met in this case. If not, the downref would need to be mentioned
in a Last Call.

This is one of the reasons draft-klensin-norm-ref is in Last Call;
although it doesn't remove the RFC 3967 procedure, it will make
things a lot clearer to anyone reviewing a draft that makes a
downref.

FWIW, there appear to be errors in the DownrefRegistry above.  For 
example, draft-ietf-lemonade-compress has not been Last Called this 
year, and when -06 version was in Dec 2006, it had no mention of 
downref.  There is a 'global'-like Last Call on 31 Jan 2007 but it seems 
to be about RFC 1951, not 1531.)




Yes, this seems odd. In fact -compress-07 cites 1951 and not 1531.

But on the other hand
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03396.html
mentions a downref to 3576 which is not yet listed. And
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03388.html
mentions a downref to 35985 which is not yet listed. There's
clearly some work to do to get this running smoothly.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Brian E Carpenter]

On 2007-03-13 20:43, Cyrus Daboo wrote:

Hi Robert,

--On March 13, 2007 3:23:22 PM -0400 Robert Sayre <[EMAIL PROTECTED]> 
wrote:



This text is actively misleading, because it suggests RFC 4346 is
included for informational purposes. The text should read:

"At a minimum, client and server implementations MUST be capable of
 being configured to use HTTP Basic Authentication [RFC2617] in
 conjunction with a TLS connection as specified by [RFC2818] and
 [RFC4346]."


The text that got used in CalDAV (which is about to be published) is:

  o  MUST support transport over TLS [RFC2246] as defined in [RFC2818]
 (note that [RFC2246] has been obsoleted by [RFC4346]);

with 2246, 2818 and 4346 all normative references. These type of 
"up-references" are not ideal and I believe there was some discussion 
going on somewhere about how better to deal with this type of situation.


You may be thinking of draft-klensin-norm-ref, which is in Last Call
as BCP through Friday this week.

Just to confirm: 2818 has already been "downrefed" so it can be used in
this way without further formality.

http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC

[Brian E Carpenter]

On 2007-03-14 04:29, David Kessens wrote:

John,

On Tue, Mar 13, 2007 at 09:04:52AM -0400, John C Klensin wrote:

If the IESG is going to claim a silent majority in favor of
approving this document, so be it.  But to claim that there were
no Last Call comments and that those that were solicited were
positive is deeply problematic.It even leads one to wonder
whether the IESG has ignored critical comments in other cases,
but I trust that has not occurred.


For the record, not everybody in the IESG was convinced that this
document should be approved considering the discussion that happened
on the IETF list.


I can testify that there would have been at least one DISCUSS if this
had stayed on the standards track, even without the Last Call comments.
But as Experimental, it seemed to me that we had no reason to
block it.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC

[Brian E Carpenter]

I saw almost no technical comments on the documents. Most of
the last call comments I saw were on a side track about
copyright issues.

The one somewhat technical comment that I logged, from Tom Yu,
didn't result in any changes but was certainly influential on
me in agreeing to the documents being reclassified from standards
track to Experimental. This could have been acknowledged in
the writeup, I guess.

Brian

On 2007-03-13 14:04, John C Klensin wrote:


--On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola
<[EMAIL PROTECTED]> wrote:


On Mon, 12 Mar 2007, The IESG wrote:

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt

...

Working Group Summary

This document set was not produced by an IETF working group,
but by an individual.  IETF Last Call produced no comments,
and solicited reviewers were basically positive.

This writeup was not updated or comments were not duly
processed.  I see 14 Last Call comments (retaining the subject
line) on [EMAIL PROTECTED], as well as 12 comments under the
'Protest: Complexity running rampant' thread.


Agreed... I was about to send a similar note when I saw this
one. 
I would add  that few of the 14 comments were really positive

about this specification.  In addition, several of the comments
on both threads asked for specific clarification of the need to
introduce the complexities inherent in an additional syntax for
accomplishing the underlying functionality.  The document has
not been modified to reflect those concerns.

If the IESG is going to claim a silent majority in favor of
approving this document, so be it.  But to claim that there were
no Last Call comments and that those that were solicited were
positive is deeply problematic.It even leads one to wonder
whether the IESG has ignored critical comments in other cases,
but I trust that has not occurred.

john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Warning - risk of duty free stuff being confiscated on the way to Prague

[Brian E Carpenter]

It is reported by The Economist dated March 10 that if you buy duty free liquids outside Europe, carry them on the plane with 
you, and have to go through airport security while changing planes in Europe, your liquids will be confiscated, assuming they 
exceed 100 ccs.


Europe in this case means the EU plus Norway, Iceland and Switzerland. If you are flying from anywhere else to Prague and 
changing planes in Europe, this will certainly apply at major airports such as London Heathrow, Paris CDG, etc., and wherever 
international transit passengers must go through security checkpoints.


To avoid losing your alcohol or perfume, they need to be in your checked 
baggage.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

When considering the Last Call comments, the IESG finally
concluded that this document should be published as an ION.

Other Last Call comments will result in editorial changes.

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)

[Brian E Carpenter]

Phill,

I'm not playing with words. The style of 'connection' involved in a SIP session
with proxies is very different from that of a classical TCP session or a
SOAP/HTTP/TCP session, or something using SCTP for some signalling purpose.
And audio or video streaming over RTP is something else again.

Java programmers that I know already open/close by DNS name without
knowing whether IPv6 is in use. But that is the plain TCP style of
session, underneath. There is a lot more than that in the network.

Brian

On 2007-03-08 19:41, Hallam-Baker, Phillip wrote:

There is this protocol called TCP that runs over IP which provides the logical 
connection.

Sniping at the use of vocabulary is not helpful here. You are refering to the 
extant architecture and so the vocaulary precisely matches the concepts you 
wish to refer to. I am proposing to make a few modest tweaks to the 
architecture. While the tweaks I propose bring it closer to the original vision 
of Cerf, Clark, Postel et al. I cannot explain it using the standard vocabulary.

My objective as an application designer is precisely to get to the point where 
the application running on top of the Internet stack can exist in blisfull 
ignorance of what is going on at the lower layers.

OK lets try code, at the moment to start up a TCP socket you have code of the 
form:

  struct sockaddr_in local, mask;
  SOCKET s;

  local.sin_port  = htons (port);
  local.sin_family= AF_INET;
  local.sin_addr.s_addr   = inet_addr(address); 


  // Create a socket
  s = socket (AF_INET, SOCK_STREAM, 0);
  Assert (s != INVALID_SOCKET, -1, ("Could not allocate socket"));

  // Bind the socket to the TCP interface and port
  int b = bind(s, (struct sockaddr*)&local, sizeof(local));
  Assert (b != SOCKET_ERROR, -1, ("Could not bind to socket"));

The application should not be dealling with any of this. The IP address should 
never be exposed to the application in any form. Same goes for the protocol.

It should be possible to define an API call of the form (again using a C idiom 
although one would hope to use C# or Java):

  s = serve ( dns_name, service_name, profile )
  s = connect ( dns_name, service_name, profile )

Where profile contains information that describes the service (protocol options, 
versions supported &ct.) on the serve call and those desired on the connect 
call. (alternatively implement via a callback structure or split connect into a 
resolution and connection phases)

I don't think that the application should know anything about the details of the IP level, not the port and certainly not the address. 



It should be possible to implement the serve and connect API using only the information in the DNS combined with a static table of information relating to legacy protocols that use the well known port scheme. 


It might be advantageous for the platform to decide to supplement that 
information with additional sources but that should not be visible at the 
application layer.


I think that this architecture is a lot more disciplined than what we have 
today. It observes the encapsulation property / layering principle much better.



-----Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 08, 2007 9:57 AM

To: Hallam-Baker, Phillip
Cc: Harald Tveit Alvestrand; ietf@ietf.org
Subject: Re: DNS role (RE: NATs as firewalls, cryptography, 
and curbing DDoS threats.)


Ah. Well I always learnt that an IP network was a 
connectionless network. Maybe you'd like to define what you 
mean by a connection.


 Brian

On 2007-03-08 14:42, Hallam-Baker, Phillip wrote:
DHCP: of course not, its routing address acquisition, not 
connection 

initiation Default Gateway: Again no connection.

DNS server: of course, it’s a tautology that interactions 
with the DNS are mediated by the DNS, but again its not 
connection initiation.


The most complicated case here is SLP. The primary problem 
in SLP is that it has failed to establish a sufficiently 
diverse adoption community. There are four competing 
protocols in the space, few signs of life in any of them.
The secondary problem in SLP is that it appears to be 
grounded in the conception of the local network being the 
locally contiguous network. Using multicast is in theory more 
scalable than Ethernet broadcast and could take the scheme 
beyond the SOHO network. In practice you have to believe in 
Tinkerbell. I don't.


Since I can do everything that SLP does using the pure DNS 
and an announcement service that is my preferred option. If 
SLP was ubiquitously supported it would be a different matter. 
Getting three out of four camps to admit that their 
proposal is not likely to make it and converge on the fourth 
is likely to be very difficult and the spec that wins is 
probably not going to do so on technical merit. Again, its 
five years since this was all promised to the consumer. 
Grafting the s

Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)

[Brian E Carpenter]

Ah. Well I always learnt that an IP network was a connectionless
network. Maybe you'd like to define what you mean by a connection.

Brian

On 2007-03-08 14:42, Hallam-Baker, Phillip wrote:

DHCP: of course not, its routing address acquisition, not connection initiation
Default Gateway: Again no connection.

DNS server: of course, it’s a tautology that interactions with the DNS are 
mediated by the DNS, but again its not connection initiation.


The most complicated case here is SLP. The primary problem in SLP is that it 
has failed to establish a sufficiently diverse adoption community. There are 
four competing protocols in the space, few signs of life in any of them.

The secondary problem in SLP is that it appears to be grounded in the 
conception of the local network being the locally contiguous network. Using 
multicast is in theory more scalable than Ethernet broadcast and could take the 
scheme beyond the SOHO network. In practice you have to believe in Tinkerbell. 
I don't.


Since I can do everything that SLP does using the pure DNS and an announcement service that is my preferred option. If SLP was ubiquitously supported it would be a different matter. 

Getting three out of four camps to admit that their proposal is not likely to make it and converge on the fourth is likely to be very difficult and the spec that wins is probably not going to do so on technical merit. Again, its five years since this was all promised to the consumer. 


Grafting the schemas developed onto an existing infrastructure everyone already 
agrees on is probably an easier prospect politically.



-Original Message-----
From: Brian E Carpenter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 08, 2007 5:13 AM

To: Hallam-Baker, Phillip
Cc: Harald Tveit Alvestrand; ietf@ietf.org
Subject: Re: DNS role (RE: NATs as firewalls, cryptography, 
and curbing DDoS threats.)


On 2007-03-08 02:06, Hallam-Baker, Phillip wrote:
OK I will restate. 

All connection initiation should be exclusively mediated 

through the DNS and only the DNS.
Would that include connections to one's DHCP server, SLP 
server, default gateway, and DNS server?


Hmm...

 Brian






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Prague

[Brian E Carpenter]

I won't ask how many we have in the Czech Republic :-)


But we have a few hundred for whom it's a short flight
and part of the same political and socio-economic block.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)

[Brian E Carpenter]

On 2007-03-08 02:06, Hallam-Baker, Phillip wrote:
OK I will restate. 


All connection initiation should be exclusively mediated through the DNS and 
only the DNS.



Would that include connections to one's DHCP server, SLP server, default 
gateway,
and DNS server?

Hmm...

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Prague

[Brian E Carpenter]

On 2007-03-07 16:58, Marshall Eubanks wrote:

I have been to Prague 3 times in the last 5 years. It is quite survivable.

However, the taxi's are ... unregulated. I would suggest that IETFers 
never take a cab on
the street. You may pay 50 Euros to go 1 km. Get the hotel, store, 
restaurant, whatever,
where you are to order you a cab, and you won't have problems. This is 
true even if there

are cabs waiting just outside where you are.


Re the airport:
http://www.myczechrepublic.com/prague/prague-airport-taxi.html

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

FYI: Daylight Savings Time discrepancy

[Brian E Carpenter]

Hi folks,

North America changes to Daylight Savings Time this weekend 10/11 March.

Europe changes two weeks later, 24/25 March, immediately after the IETF.

This has consequences.

1. During those two weeks, the time difference between North America
and Europe will be one hour less than usual. For example 9:00 a.m.
in New York will be 14:00 p.m. in Prague. Please bear this in mind for
planning any conference calls, remote participation in the IETF, and
adjusting your watch on arrival in Prague.

2. There are predictions that some calendaring software will get
very confused during those two weeks, due to the late change of
date for North America. So don't trust your software without
checking.

http://www.timezoneconverter.com/ is helpful.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: The Devil's in the Deployment RE: NATs as firewalls

[Brian E Carpenter]

Noel,

On 2007-03-04 22:36, Noel Chiappa wrote:

> From: Brian E Carpenter <[EMAIL PROTECTED]>

> the problems that NAT causes, and that having suffcient address space
> (a.k.a. IPv6) solves

This comment seems to posit that insufficient address space is the only thing
driving deployment of NATs (other than the modestly effective firewalls that
NAT provides), and that's just not correct.


No, that wasn't my intention. It's more narrowly argued: the *problems* that
NAT causes are solved by having enough address space; the claimed security
features are actually firewall features. But that leaves a third piece: the
use of NAT to help with the multihoming and renumbering conundrum. However,
that I think belongs over on the RAM list.

Brian



Until the IETF fully understands and appreciates the forces which are driving
the deployment of NAT boxes - which have been spectacularly successful in the
marketplace, far more so than the purported official alternative - they will
continue to eclipse said purported official alternative.

Noel

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: NATs as firewalls

[Brian E Carpenter]

John,

(after also reading Michael's response)

I don't disagree. I think there is scope for writing a list of
desirable properties for SOHO routers in the light of these
various inputs. I'm less certain it can be done for enterprise
boundary routers. But it would be a tricky and contentious job
in both cases. Even draft-ietf-v6ops-nap took many moons
and several major editing passes, and it only starts the work.

Brian

On 2007-03-04 22:39, John C Klensin wrote:


--On Sunday, 04 March, 2007 20:05 +0100 Brian E Carpenter
<[EMAIL PROTECTED]> wrote:


Michael,

On 2007-03-02 16:19, [EMAIL PROTECTED] wrote:
...

No real disagreement here but I do see a way forward. First,
clarify the terminology. Second publish a pair of RFCs rather
like 1009 entitled "Requirements for Consumer Internet
Gateways" and "Requirements for Enterprise Internet
Gateways". 

Are you aware of RFC 4084 "Terminology for Describing Internet
Connectivity"?

It is a rather different take on the same problem.


But it really doesn't address the gateway hardware and software
itself, but only what is provided to the customer boundary.  If
an IT/ networking person for a moderately small network can't
walk into the local computer vendor and buy a boundary router
and/or firewall that will support IPv4 and IPv6 without NATs or
similarly-hostile addressing tricks or transformations, then
nothing we do helps very much.  And, having just taken another
look at draft-ietf-v6ops-nap-06.txt, while it is clearly a step
(or several) in the right direction, I don't see it moving me
much closer to that walk into the local computer store, much
less the ability to take it with the circa USD 50 - USD 100 in
my hands that will buy a competent IPv4 Router-NAT-Firewall
today.

It also ignores one issue that 4084 does address: many of the
ISPs supplying services who serve what you describe as the
"small private network" market have discovered a significant
revenue opportunity in restricting most customers to two or
fewer public   addresses.  Simply crossing that threshold into
availability of even a small number of relatively stable public
addresses is often the excuse for pricing differences that may
approach an order of magnitude.  Sometimes that difference is
justified by claims about service quality that the customer
cannot measure or unbundle, sometimes by lifting of
prohibitions, and sometimes by address scarcity but the reality
is that, having discovered this revenue opportunity, there is
reason to believe that ISPs would be unlikely to let go of it
even if there were no scarcity argument available.

Incidentally, in my experience, those "small private" networks
somewhat more than ten hosts if the real entry threshold for the
"medium/large" ones is "sufficient resources to acquire
addressing independence" (section 5.1 of v6ops-nap-06).  If that
is really the criterion, and "addressing independence" implies
PI address space, the number of networks in the range between
what is usually thought of as the "residential" or "SOHO"
category and the PI threshold is 
quite large, growing, and includes many medium-sized enterprises

and networks.

Please remember that, unlike some of the other contributors to
this set of threads, I strongly dislike NATs, believe we should
be migrating to IPv6 much more quickly than we have been, and
that continued fussing by the IETF about IPv6 details and
options has become part of the deployment problem.  But I also
think that we are most likely to make progress on these problems
by being as clear-headed and objective about them as possible.
That includes understanding that having the IPv4 network
environment persist into this century --no matter how horrible
the kludges are that are required to support it-- is building it
own inertia against wide or rapid IPv6 deployment as people
discover economic advantages and build operational practices
around those kludges.  Those advantages and practices may be
harder to overcome than the technology barriers (real or
imagined) themselves.

 john



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: The Devil's in the Deployment RE: NATs as firewalls

[Brian E Carpenter]

On 2007-03-02 17:09, Hallam-Baker, Phillip wrote:
From: Brian E Carpenter [mailto:[EMAIL PROTECTED] 


This is of course one of the major motivations for 
draft-ietf-v6ops-nap-06.txt, which is now in the RFC Editor's 
queue. While it doesn't tell SOHO gateway vendors exactly 
what to do, it does I think make it clear that there is a 
secure mass market IPv6 way forward that has no need for NAT.


This is exactly the type of implict statement that I was concerned about.

I am a practical person. 


I try to be one of those too, but analysis precedes synthesis.

The governing principle becomes Default-Deny. 


That is completely compatible with the above draft.


The fixup required to make NAT work is neither complex nor onerous.


But irrelevant - the problems that NAT causes, and that having suffcient
address space (a.k.a. IPv6) solves, are orthogonal to security. That is
the whole point in this thread.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: NATs as firewalls

[Brian E Carpenter]

Michael,

On 2007-03-02 16:19, [EMAIL PROTECTED] wrote:
...

No real disagreement here but I do see a way forward. First, clarify the
terminology. Second publish a pair of RFCs rather like 1009 entitled
"Requirements for Consumer Internet Gateways" and "Requirements for
Enterprise Internet Gateways". 


Are you aware of RFC 4084 "Terminology for Describing Internet Connectivity"?

It is a rather different take on the same problem.

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: NATs as firewalls

[Brian E Carpenter]

On 2007-03-01 18:57, John C Klensin wrote:
...

I continue to believe that, until and unless we come up with
models that can satisfy the underlying problems that NATs
address in the above two cases and implementations of those
models in mass-market hardware, NATs are here to stay, even if
we manage to move to IPv6 for other reasons.  And, conversely,
the perceived difficulties with NATs will be sufficiently
overcome by the above issues to prevent those difficulties from
being a major motivator for IPv6, at least for most of the
fraction of the ISP customer base who cannot qualify for PI
space.



This is of course one of the major motivations for
draft-ietf-v6ops-nap-06.txt, which is now in the RFC
Editor's queue. While it doesn't tell SOHO gateway
vendors exactly what to do, it does I think make it clear
that there is a secure mass market IPv6 way forward that
has no need for NAT.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

[Brian E Carpenter]

On 2007-02-28 17:02, Hallam-Baker, Phillip wrote:

The core assumption here seems to be that NAT is a bad thing so lets get rid of 
NAT rather than trying to make NAT work.


This is startlingly irrelevant to the present document. We have a large corpus
of documents about the issues caused by NAT and about partial solutions. But
this document is about NAT-PT, which is something else.


The questions that I would like to see answered that I don't see in the 
document are

1) What is the deployment strategy for IPv6 without NAT?


As Fred has pointed out, there is also a large corpus of documents
about this, and it's clearly out of scope for the present document.


2) Are people actually using or deploying NAT-PT?


Had you read the draft carefully, you would know that
  "From a deployment perspective, 3GPP
   networks are currently the only 'standardised' scenario where an
   IPv6-only host communicates with an IPv4-only host using NAT-PT as
   described in the 3GPP IPv6 transition analysis [RFC4215], but NAT-PT
   has seen some limited usage for other purposes."


3) Exactly why should an application be invited to care about this issue?


Others have responded on this, but to summarise: an application that
assumes addresses have end to end validity will fail. That much, NAT-PT
has in common with NAT.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

[Brian E Carpenter]

Good catch - that seems to be a little obsolete text that's
sitting around in the I-D tracker. The draft itself is
clear that Historic is the intention.

Brian

On 2007-02-28 15:07, Elwyn Davies wrote:

Just to clarify the current situation...

The statement below says that the recommendation is for RFC 2766 to be 
reclassified to experimental..  As is implied by the title of the draft, 
it actually recommends reclassification to Historic.


This error results form a piece of history ;-) - The draft is 
fundamentally the same as draft-v6ops-natpt-to-exprmntl-03.  The change 
in recommendation has been necessitated because it appears that RFC 2026 
does not allow the transition to experimental.  In the meantime it has 
become ever more clear that NAT-PT is of dubious value and could limit 
the development of IPv6 over time.


Regards,
Elwyn

Brian E Carpenter wrote:

I think it's important to publish this document, to make it
clear why NAT-PT is a solution of very dubious value.

Brian

On 2007-02-27 20:14, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) 
to consider the following document:


- 'Reasons to Move NAT-PT to Historic Status '
as an Informational RFC

This document recommends that the IESG reclassifies RFC 2766 from
Standards Track to Experimental status.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

[Brian E Carpenter]

I think it's important to publish this document, to make it
clear why NAT-PT is a solution of very dubious value.

Brian

On 2007-02-27 20:14, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to 
consider the following document:


- 'Reasons to Move NAT-PT to Historic Status '
as an Informational RFC

This document recommends that the IESG reclassifies RFC 2766 from
Standards Track to Experimental status.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP

[Brian E Carpenter]

On 2007-02-26 07:51, Eliot Lear wrote:

Sam Hartman wrote:

My strong preference as an individual is to approve this document as
is.  I think there's a good split between RFC 3967 and this document.
RFC 3967 will cover informational documents; this document will cover
standards track.

I'm not in principle opposed to having one document but I am opposed
to the delay it would introduce.
  


It's not just one more document.  We're working on at least a dozen, 
starting with RFC 2026, going on to various "IOPs", the boiler plate 
documents, IESG sponsorship documents, IRTF rules, and more.  One has to 
be an Internet lawyer to understand the system.


Which is why we have the Tao and
http://www.ietf.org/IESG/content/ions/ion-procdocs.html

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP

[Brian E Carpenter]

I believe that if we follow the authors' suggestion
to proceed rapidly, Tom's concern could be met by
a simple informational note summarizing how to deal
with downrefs in practice. Such a note could be input to
an eventual combined document after some experience,
as John suggests.

Brian

On 2007-02-25 00:00, John C Klensin wrote:



--On Saturday, February 24, 2007 4:09 PM -0500 Sam Hartman 
<[EMAIL PROTECTED]> wrote:



"Tom" == Tom Petch <[EMAIL PROTECTED]> writes:


Tom> I have no problem with the underlying idea, in so far
as I Tom> understand it, but I do not agree that this I-D
is the best Tom> way to achieve it.

Tom> I think that my problem is well illustrated by a
sentence in Tom> the Abstract ' This document replaces the
"hold on normative Tom> reference" rule will be replaced
by a "note downward Tom> normative reference and move on"
approach. ' As may be Tom> apparent, this brief - three
pages plus boilerplate - I-D, Tom> aimed at BCP status,
only partly updates or replaces BCP97 Tom> (also three
pages plus boilerplate) so we will in future have Tom> to
conflate two documents to understand what is on offer.

My strong preference as an individual is to approve this
document as is.  I think there's a good split between RFC 3967
and this document. RFC 3967 will cover informational
documents; this document will cover standards track.

I'm not in principle opposed to having one document but I am
opposed to the delay it would introduce.


Tom,

This is very much up to the IESG, but my personal opinion is that we are 
better off putting this draft through as is and then coming back and 
revisiting the situation in a year or so, once we have gotten some 
experience with the combination.  My guess -- harking back to the 
original "process experiment" theory -- is that some tuning is going to 
be needed and that there is no point in tangling 3967 up with the tuning 
process.  That assumption is particularly important because Sam's 
observation of 3967 for informational (and experimental) documents and 
this for standards-track is what I'm expecting too... but it is an 
assumption.  One can imagine the community responding to a downref under 
this procedure for a particular document by saying "just too dangerous 
to do it that way; let's use the 3967 procedure in that case".   We 
might be willing to eliminate that possibility once we have some more 
experience, but I'd think it would be dangerous to do so right now.  So, 
for the present, we have this procedure for standards-track documents 
when it seems appropriate and 3967 for everything else.


In a year or two, if anyone cares, we can fold the two together on the 
basis of actual experience (or fold both into the long-avoided 2026bis).


   john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Identifications dealing with Bulk Unsolicited Messages (BUMs)

[Brian E Carpenter]

The level of bulk unsolicited messages exceed more than 90% of the volume in 
many cases


I estimate 95% of moderated non-member mail that hits the IESG list to be b.u.m.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Identifications dealing with Bulk Unsolicited Messages (BUMs)

[Brian E Carpenter]

On 2007-02-21 17:07, Tony Finch wrote:

On Wed, 21 Feb 2007, Brian E Carpenter wrote:

Blacklists at the level of sending domains (or reputation systems
that function like blacklists) are a failure.


I was talking about IP address blacklists.


Right. That can work, of course.


Perhaps 90% was a bit
over-optimistic - my stats from cam.ac.uk show more than 80% of spam dealt
with by DNS blacklists and another 10% with a few other simple checks.


Interesting. Do they also run content filters?

   Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Identifications dealing with Bulk Unsolicited Messages (BUMs)

[Brian E Carpenter]

On 2007-02-18 13:46, Tony Finch wrote:

On Sun, 18 Feb 2007, Harald Tveit Alvestrand wrote:

If this was effective, blacklists would have solved the spam problem.


They are 90% effective 


You what? Which Internet would that be?

Blacklists at the level of sending domains (or reputation systems
that function like blacklists) are a failure. Maybe you are fortunate
and dotat.at is not blacklisted. You won't feel so fortunate when
it does get blacklisted one day, if you happen to find out why
your mails are being dropped.

 Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Does our passport need to be valid for 6 months to go to Prague?

[Brian E Carpenter]

On 2007-02-19 00:57, Michael StJohns wrote:

At 06:29 PM 2/18/2007, Janet P Gunn wrote:


My guidebook says 6 months.


Feel free to argue with the US State Dept..   :-)


The US State Dept web info is inconsistent with the Czech Embassy
web info. We are trying to get definite confirmation from
an official Czech source.

http://tinyurl.com/2edh4m is the list of Czech consulates worldwide,
if you want to check personally.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn)

[Brian E Carpenter]

On 2007-02-20 15:31, Fred Baker wrote:


On Feb 20, 2007, at 8:15 AM, Georgios Karagiannis wrote:


I assume that you also have no objection on using the DSCP fields for
this purpose.


actually, I do, at least in some ways that they might be used. The AF 
service (RFC 2597) is specifically designed to do as you say; EF isn't. 
setting the DSCP on an EF packet in a way that nullifies its EF behavior 
to communicate the onset of congestion mostly nullifies the EF service 
(which doesn't actually do much of anything when there is no congestion 
to perturb packet timing). So I would want any use of the DSCP to be 
coordinated with the other services that the datagram hopes for.


Exactly. The allowed uses of the DSCP are constrained by RFC 2474
and PCN can't go outside those constraints without causing unpredictable
breakage. That needs to be explicit in the charter, I believe.

While I'm writing, consider this assumption:


(A) these components are deployed in a single DiffServ domain,
where all boundary and interior nodes are PCN-enabled and
mutually trust each other


That is fine from the point of view of the diffserv architecture,
which is strictly domain-based. However, it isn't a get out of
jail card for security: BCP 61 (RFC 3365) still applies. The
comment about mutual trust should probably be removed.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

About Gen-ART reviews

[Brian E Carpenter]

Hi,

As devoted readers may have noticed, quite a few Gen-ART reviews
have been copied to this list recently, with follow-up postings
in some cases.

Is this a good or a bad thing?

Comments welcome.

Brian (as General AD)

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

Frank,


Don't they also set the "pubreq" bit in the I-D tracker ?


Very possibly, but that is just a progress tracking issue.
I agree we need a progress tracking mechanism, but that
isn't the underlying point here, which IMHO is to get the
author in discussion with the appropriate AD.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

Frank

On 2007-02-10 01:07, Frank Ellermann wrote:


...  I don't like this draft, "send publication
request to secretariat" is more attractive than spamming ADs.


You probably need to understand what happens when someone
does that. The Secretariat simply forwards the note to the
IESG. After a while, the IESG Chair will (with luck) have
handled everything that looks urgent, and will take a glance
at draft-smith-my-new-idea and make an uninformed guess that it
fits the smurf Area. (So far, elapsed time is a couple of weeks
wait plus 3 minutes attention.) The IESG Chair will send a note
to one or both smurf ADs saying "Can you have a look at this?".
And then the process proposed by draft-iesg-sponsoring-guidelines
actually starts - probably with another wait until one of
those ADs has handled everything that looks urgent.

It makes a lot more sense, IMHO, for the author to decide
that her work fits the smurf Area and write directly to the
ADs. In either case, the first real step is for those ADs
to look at the draft and respond to the author.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

Frank,

On 2007-02-09 17:04, Frank Ellermann wrote:

Jari Arkko wrote:


I would be happy to sponsor a ternary bit draft, but only on
April 1 :-)



What I don't like in your draft is the (apparent) personal veto
right for the AD.  Authors (hopefully) have an idea about their
topic, but they don't need to be procedural experts.  They don't
need to know what an "area" is, if it has a catchall WG or not,
and who the area directors are if it has no such WG.

They decide when their memo is ready to be published as RFC,


No, that is not their decision. They decide that they would
*like* the document to be published as an RFC. And frankly if
someone's understanding of the IETF is such that they can't
even decide which Area is likely to be appropriate, I have to
wonder why they think they are ready to publish via the IETF.


and
what follows should be a simple procedure:  Send a "publication
request" to the IESG (maybe to a public list), get a responsible
AD, work it out. 


That doesn't actually work. Sending a message to a group of
very people is roughly like sending it to /dev/null. That's
exactly why we want to change this.


The IESG or AD could tell them that the memo
belongs to an existing WG, that it's not in a shape to waste the
time for an IESG evaluation with it, and maybe that it's anyway
hopeless.

It's okay if there are shortcuts for authors knowing precisely
which area and AD they want, but generally authors shouldn't need 
to know this.  


Disagree, see above.


If the IESG refuses to pick a responsible AD for a memo the author
should have a right to appeal.


Actually, the way we interpret RFC 2026, there is always a right
to appeal, whatever we write in this document.


With some chance authors would see
that their appeal will be decided by the same group who refused to
deal with their text in the first place, and don't try this.


That's why there is a 2nd level of appeal.


But
maybe they want this situation on public record, because then the
"community" can check what's going on - "oh, Leibniz didn't speak
Chinese and erroneously stated there are only 64 trigrams for six
bits" or whatever the problem might be.


Sure, a public record is good.

 [catchall WGs in some areas] 
the draft says relatively little about this, because there are 
different situations. Some areas have a general purpose area 
working group with chairs and an ability to produce documents

just like any other WG.


I certainly didn't know this before I read your I-D, it could be a
good idea.  Or not, depending on the catchall WG, if they refuse
to consider anything NIH.


That's why we also have Independent Submission, I think.


What if they don't like it, but the authors still insist on
an evaluation ?  Can they appeal then ?  What if the AD
does not like it personally, but admits that it's not as
bad as the famous ternary bits ?


As with regular WG submissions, the document has to pass the 
responsible AD's review. Otherwise it goes back to the WG or

the authors.


That's apparently a side effect of the "must vote YES" rule.  One
part of it is clear, don't waste the time of the complete IESG if
the memo isn't in a shape for serious considerations.  But it's
a bad rule if the AD "only" doesn't like the memo, while others
could think it's okay.


True, if the NomCom appoints bad ADs...


With your draft you'd introduce a third point of failure - before
potential post Last Call "RFC editor note" or "AUTH48" mutilations
of a draft - a single AD can veto and kill anything as it pleases
him or her.


No, the draft introduces nothing new at that stage - it's only
the very first step that is changed from what's been done for
many years.


Ask another AD ?  Your draft tries to block that escape hatch.


Perhaps for ternary arithmetic, but not for something that
really belongs to another Area.


Try "independent" ?  John's draft tries to block that too.


No


 Last
solution, authors should start with "independent" if they're not
interested in arbitrary AD decisions.  If they try "individual" 
they'd be doomed if that fails.


No, in fact a common reply from an AD might be to recommend
independent submission if the work is interesting but really
outside IETF scope.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on AreaDirector Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

- I'm lost about why we would continue to publish Informational process 
RFCs (ignoring any existing pipeline of process documents remaining to 
be published as RFCs).


To me the argument for making this one an RFC is mainly that it
fits together with the two other drafts mentioned previously,
which pretty clearly need to be RFCs. But it wouldn't give me
any heartburn if the community consensus is to make it an ION.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

On 2007-02-08 14:05, Scott O. Bradner wrote:

But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.


rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no way would block a 4-week last call for an informational RFC
- note that RFC 2026 does not require any last call for informationals

fwiw - I agree with John - this doc warents a longer last call because
it does impact how part of the IETF process will work and the draft
did not get vetted in a normal working group process


As I said, this won't be rushed through. Let's see if there are any
comments of substance though.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

John,

On 2007-02-08 13:16, John C Klensin wrote:


--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
<[EMAIL PROTECTED]> wrote:


Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because we wanted to get the
two in sync. I think we are more or less in sync but the
remaining input should come from the community.

As for the list to use for discussion -- sending mail to the
iesg list only would indeed be one way. The discussion list
we are on right now seems more suited, no?


Sure.  But my point in that area was obviously not clear.  Prior
to the announcement of the Last Call, there was no indication to
the community that this document should be considered and
discussed, much less where.  There is no working group charter,
no history of open discussion, and so on.   And _that_ calls for
a four-week Last Call, not two weeks.


The rules require a 4 week last call for non-WG standards actions,
which this isn't, so the tracker automatically generated a 2 week
last call. But I assure you that discussion will not be truncated
arbitrarily as a result (i.e. I do not intend to rush this onto
the IESG agenda for Feb. 22).

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

John,

On 2007-02-08 00:02, John C Klensin wrote:

Hi.

I will get to substance in a separate note, and hope others will
also.  In the interim, two procedural remarks...

(1) This document and draft-klensin-rfc-independent-05.txt
describe two pieces of the "how a document that does not
originate in a WG may be reviewed and published" space.  Each
contains some text that suggests that some documents are better
handled via the other path. The IAB has made a request for input
on the "independent" document and now we have a Last Call on
this one.  


As editor of the "rfc-independent" document, I am awaiting
instructions from the IAB as to what, if anything, to do next,
but suspect that the recommendation below would be better
applied to -06 rather than -05 of that document.

I strongly encourage members of the community to review the two
documents side by side to ensure that everyone is satisfied that
they are consistent and that any questions about the overall
non-WG submission space is adequately covered by one or the
other of them.


Exactly right. These documents (and draft-iab-rfc-editor) need
to interlock and that is why they are open for review at the same
time.



I also ask, and hope others will join me in asking, that the
IESG and IAB take explicit responsibility for coordinating and
ensuring consistency between these two documents (and, if
necessary, with draft-iab-rfc-editor).  If they are not
consistent enough that actions based on them are predictable, I
fear we can look forward to some difficulties.  It might even be
useful for the two groups to coordinate titles sufficiently that
someone looking for information will easily understand that the
two describe somewhat parallel paths and ways in which those
paths may or may not be alternatives to each other.


That is the intention; and we can indeed look at the titles
in that light.



(2) This document is not the product of a working group or of
extended open discussion in the community.  Version -00 was
posted around the time of the San Diego meeting and received
very little public discussion.  The current version was posted
at the beginning of this month; there has been little discussion
of it either (at least on public lists -- as the
Acknowledgements suggest, I've had some input into it via
private discussions).  The document does not even indicate a
mailing list on which it can be discussed.  One presumes that
comments could have been sent to the IESG by those who happened
to read the I-Ds, but that is a one-way communications path.  


Well, the Last Call message suggested this list. And with one rather
small difference, the draft only attempts to describe current practice.
[The difference is that it calls for a publication request to be sent
to a single AD and not to the IESG as a whole.]


If the IESG intends this document to merely represent the
particular procedures they intend to follow within the range of
alternatives over which they believe they have discretion, then
it should probably be published as an ION, not an Informational
RFC. 


We discussed this and reached the opposite conclusion, mainly
because of the point you raise above: consistency with two
other documents that will definitely be RFCs. But it was a
close decision.


If they intend it to be definitive information for the
community, especially information that they expect to reference
as to why something is or is not possible or whether procedures
are being followed, a two-week Last Call is, IMO, inappropriate
and inconsistent with the spirit of the provisions in RFC 2026.


If we believed it modified or did violence to 2026, it would need to
be a BCP itself with a whole other style of review. But since its
intent is much milder, a normal LC seemed enough.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Brian E Carpenter]

On 2007-02-08 01:25, Frank Ellermann wrote:

John C Klensin wrote:


If the IESG intends this document to merely represent the
particular procedures they intend to follow within the range of
alternatives over which they believe they have discretion, then
it should probably be published as an ION


Not publishing it at all is an alternative.  It would send an
unmistakable message to wannabe-authors, that they should use the
"independent" path, unless they're a friend of a friend of an AD.


That is a complete mischaracterization. The intent in publishing
this (and doing so in parallel with draft-klensin-rfc-independent)
is to make it much clearer to authors when they should choose one
path and when they should choose another.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [Gen-art] Re: Gen-ART review of draft-ietf-l2tpext-failover-11.txt

[Brian E Carpenter]

I'm going to No Objection and I suppose you'll do an RFC Editor note.

   Brian


On 2007-01-30 16:39, Mark Townsley wrote:


On second look, this is rather small. Vipin, I can do either. If you 
wish to provide me text in "OLD" "NEW" format, or a new document.


- Mark

Suresh Krishnan wrote:

I am the assigned Gen-ART reviewer for
draft-ietf-l2tpext-failover-11.txt

For background on Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:

Minor:
==

* IANA considerations

The IANA considerations section does not specify the namespace from 
which allocation is requested for the AVPs and the message types.



Editorial:
==

* Section 4.2 Failover Session Response

This sentence has a typo and does not read well

"It is not required to respond one FSQ message with just on FSR."

I suggest removing it altogether so that the text will simply read

"An endpoint MAY choose to respond to an FSQ message with multiple FSR
 messages"



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ion-procdocs open for public comment

[Brian E Carpenter]

On 2007-02-01 20:06, Frank Ellermann wrote:

Brian Carpenter wrote:


http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html


I liked the I-D better, the xml2rfc HTML output is hard to read.


Really? I find the links in the HTML version invaluable.


For an ION you could probably remove the dummy chapters 3 and 4.


Correct, thanks.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Referencing BCPs [Re: ion-procdocs open for public comment]

[Brian E Carpenter]

On 2007-01-31 18:47, John C Klensin wrote:


--On Wednesday, 31 January, 2007 17:02 + "Steven M.
Bellovin" <[EMAIL PROTECTED]> wrote:


On Wed, 31 Jan 2007 11:54:26 -0500
John C Klensin <[EMAIL PROTECTED]> wrote:


Except for the fact that the material being cited contains the
specifics of license and IPR releases, and promises to abide
by certain rules, by the authors.  Authors can't reasonably be
asked to agree to something that might be published under the
BCP number in the indefinite future, so you are either stuck
with a document (RFC) number or a BCP as of a specific date,
which amounts to the same thing and is harder to track down.


I agree. If someone says "where are the IETF copyright rules?"
the citation is BCP 78. If they say "where are the copyright
rules for RFC 3704?" the citation is RFC 3667.




I'll let Jorge correct me if I'm wrong, but referencing by
 is the norm in the legal world, since statutes
do get amended without necessarily being renumbered.


I believe that is correct.  The problem here is that, as a
consequence of that referencing system, they have taken measures
to be sure that the version corresponding to the reference is
readily available.  We don't do that: finding out what was
actually BCP NNN on some particular date requires both skill and
out of band knowledge.


I do agree we want to make it easy for non-lawyers.  I've
suggested a date-stamped archive of each version of each such
document, for precisely that reason. 


That, of course, would do that job and eliminate all of my
objections.  But it does mean that, for many purposes, we can't
use a reference to "BCP ", it must be a reference to "BCP
 as of mmdd" or its equivalent.


I simply observe that we are experimenting with date stamping
in the case of IONs, with the latest versions in
http://www.ietf.org/IESG/content/ions/ and the dated versions in
http://www.ietf.org/IESG/content/ions/dated/.
We'll see how that works for us.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Referencing BCPs [Re: ion-procdocs open for public comment]

[Brian E Carpenter]

On 2007-01-31 00:35, Ned Freed wrote:
...

More generally, I have a problem with normative cituations to BCP and STD
numbers since the underlying document can change. That's arguably OK for an
informational citation, but IMO normative references may have version
dependencies that need to be taken into account.


I think that is absolutely correct for technical specs. In the specific case
of the IPR process documents, which Spencer raised, it may well be that
the correct citation should be the latest version. (But not in all cases;
when discussing the copyright status of RFC mumble, the copyright rules
in force at the time of publication may be the correct citation.)

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ion-procdocs open for public comment

[Brian E Carpenter]

On 2007-01-30 13:59, Spencer Dawkins wrote:





What I'm talking about is that if you type in BCP 9 in the RFC Editor 
search engine, the only RFC that pops up as part of BCP 9 is 2026, but 
the RFC Index says "Updated by RFC3667, RFC3668, RFC3932, RFC3979, 
RFC3978".


This is a special case, because those documents are BCP 78, 79 and
92 respectively (i.e. someone decided to give them distinct BCP
numbers). If you look for, e.g., BCP 101 you will get both RFC 4071
and RFC 4371. So, it all depends.



On the other hand, this ION is an "Informal Guide". If you think it's 
better to say "we wouldn't dream of changing BCP procedures in an ION, 
but we do note that as of  this procedure hasn' been followed 
since it was oriiginally described in RFC 1310, there are no known plans 
to follow it, there has never been an appeal because we don't follow it, 
and there has never been an AD recall petition because we don't follow 
it", that seems like something I'd hope a guide would tell me.


Could you ping the rest of the IESG and see whether this reasoning seems 
flawed? 


Sure, when the comment period expires and I roll up all the comments.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

ION typos [Re: ion-agenda-and-minutes open for public comment]

[Brian E Carpenter]

I also noticed "providessuggestions " as a typo, which does make me 
wonder - we rely on the RFC Editor for proof-reading, but we're not 
sending IONs to the RFC Editor. Is there a plan?


IONs are less formal, so I think the honest answer is "no". And
we are certainly not going to apply any style book rules.

   Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ion-procdocs open for public comment

[Brian E Carpenter]

On 2007-01-29 18:08, Spencer Dawkins wrote:
I should begin by thanking Brian for producing this document, both 
originally and in ION format.



An ION (IETF Operational Note, see RFC 4693) is open for public comment
on the ietf@ietf.org list. Comments should be sent by 2007-02-12.

Please see
http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html


I'll limit my comments to a "huh?" and a "grrr"...

"Huh?" - this document refers to IETF BCPs by RFC number, not by BCP 
number. The text says "Most of the cited RFCs are BCPs. RFC numbers have 
been used rather than BCP numbers, for convenient lookup."


I'm having a hard time understanding what lookup mechanisms are less 
convenient for BCPs than for RFCs 


My assumption, maybe false, is that a lot of people have RFC mirrors and
relatively few have BCP mirrors. Also, my xml2rfc skills don't extend to
knowing whether I can directly cite BCPs in xml2rfc and get pointers
to the BCP and not the RFC. I'm willing to be educated on that point ;-)

(the RFC Editor search engine at 
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl returns BCP numbers and 
STD numbers along with RFC numbers when you search for text, and returns 
BCP numbers when you search by number and click the selector for "BCP"), 
but the more serious concern is that RFC 2026 (for instance) is NOT the 
complete standards process  in any meaningful way, since it has been 
updated 5 times so far (according to the RFC Editor search engine).


The IETF website has just updated pages that said "2026 = standards 
process" to say something like "2026 as updated = standards process" 
(http://www.ietf.org/IETF-Standards-Process.html on the main IETF web 
page used to be a direct link to 2026, but it's not any more.). Going 
back to "RFC 2026" in IONs is a step backward.


Be specific. Which RFCs that update 2026 are not cited?


I don't know why the updates are not also part of BCP 9, but they should 
be. One Might Think. I'd rather fix that, than start training people to 
ignore the updates AGAIN...


If they were approved as formal updates, that is logged in the RFC Index.
If they weren't approved as formal updates, then they have to be regarded
as stand-alones.


"Grrr" - One Might Think that Newtrk is still active, from reading 
Section 2.2, "The newtrk WG was chartered to revise the standards track 
- multiple proposals have been floated, but no conclusions have been 
reached", but it has concluded.


Yes, I need to fix that text.

From what I can tell, draft ION 
correctly identifies missing documents that might usefully exist, but 
does not give any clue that parts of RFC 2026 are just flat-out ignored 
(see: RFC 2026, section 6.2, describing the periodic review of proposed 
standards and draft standards that we don't do).


My own expostulations on that topic are at
http://tools.ietf.org/id/draft-carpenter-rfc2026-critique

I don't know why we would publish this ION ("Informal Guidance") without 
saying this. There are things in 2026 that we have argued about whether 
we do or not, but no one thinks we have ever done these reviews.


But an ION isn't supposed to change any rules, so I don't think it
should even say that certain rules are not followed.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: submitting an ID

[Brian E Carpenter]

When I was in school, I was taught to quote multiple paragraphs with 
quotes at the start of each and a closing quote only at the end of the 
final paragraph.


So was I, but whether or not this is a typo doesn't affect what you
put in an I-D, which doesn't have the quotation marks anyway,
except of course those in '"AS IS"'.

Use XML2RFC and you simply don't have to worry about this anyway.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Tracking resolution of DISCUSSes

[Brian E Carpenter]

On 2007-01-18 09:49, Tom.Petch wrote:

Who is shepherd for an individual submission?


The sponsoring AD. However, draft-iesg-sponsoring-guidelines
(which will be updated shortly, so don't worry about
its terminology issues) adds:

   Once the AD has agreed to sponsor a document, the authors need to
   provide a write-up similar to PROTO team write-ups from WGs.

 Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Tracking resolution of DISCUSSes

[Brian E Carpenter]

On 2007-01-17 16:41, Dave Crocker wrote:



Brian E Carpenter wrote:

I think you are deeply misunderstanding how PROTO shepherding is
supposed to work.


That's a pretty basic disconnect.

Perhaps you can summarize how it is supposed to work?


The way it's described in draft-ietf-proto-wgchair-doc-shepherding,
which makes it plain to me that the shepherd is taking
responsibility for ensuring that issues are resolved through
open process.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Tracking resolution of DISCUSSes

[Brian E Carpenter]

We're rapidly approaching diminishing returns here...

On 2007-01-16 21:17, Michael Thomas wrote:

Brian E Carpenter wrote:

On 2007-01-15 17:11, Michael Thomas wrote:



Michael Thomas, Cisco Systems

On Mon, 15 Jan 2007, Brian E Carpenter wrote:




Why not simply:
- copy all Comments and Discusses to the WG mailing list
- hold all discussions on the WG mailing list until resolution


Why would we do this for technical typos and other things that
are essentially trivial? I'd expect an AD to enter WG discussion
when raising fundamental issues, but not for straightforward
points.


  This seems sort of like a red herring to me: typo posts
  typically don't elicit much wg discussion in my experience.
  But please help me here: it seems that DISCUSS as currently
  instantiated is a conversation between the authors/wg chairs
  acting as liasons with the IESG. This sets up sort of a
  representative democracy kind of situation vs. a direct
  democracy that would be a conversation directly on the wg list.
  I can understand the IESG's desire for filtering, but that does
  place a lot of power in the hands of the wg's representatives.
  And power always begats abuse at some point... is this really
  what was intended?


Abuse wasn't intended, obviously, but delegation was.

Put simply, ~200 WG Chairs scale better than ~16 ADs.

 

This rather assumes that the chairs and/or authors are always able
to remember not only the material that is currently before the IESG, but
also the history of how it got there. As an author, it's hard enough to
keep track of the former and the latter is back in the realm of the 
super-human
again. 


That is even more true for the ADs, who see several hundred drafts
a year on their screens. Authors and WG Chairs are *much* better placed
to remember the history and context than an AD. ADs have to look back
in the tracker and email archives each time they need context.


So when you get a DISCUSS which may well involve the intricacies
of a very long and hard slog in the working group where many competing
parties finally agreed to a consensus... how as the representatives do 
you know
whether you are telegraphing the will of  the working group? It's very 
hard,
and at a late date it is *very* easy to make very basic mistakes again 
which

not only negate the consensus of the working group, but are potentially
just plain wrong. And that's assuming that there are no agendas, hidden or
otherwise.


Yes. Which is exactly why substantive issues are to be taken back to
the WG by the PROTO shepherd. Nobody is arguing otherwise, I hope.

So all in all, for an otherwise rather direct democratic kind of 
institution, I

find the implied(?) representative nature of the backend linkages, non-
transparency of process,  and the juxtaposition of a 
fresh-but-disinterested

ruling body next to the inured-but-interested working group sets the stage
for a lot of potential process problems/abuses/surrender-and-ship-it 
kind of

outcomes. That doesn't seem right.


I think you are deeply misunderstanding how PROTO shepherding is
supposed to work.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Tracking resolution of DISCUSSes

[Brian E Carpenter]

Ralph, I think I've already indicated why I (and others)
believe that systematically posting raw DISCUSSes to lists
would be the wrong move.

Brian

On 2007-01-15 20:43, Ralph Droms wrote:

Following up on that, I suggest a requirement that any DISCUSSes be posted
to that mailing list, along with conversation/resolution of the DISCUSSes.
I would very much like to see those last steps out in the open.

Only drawback to separate mailing list is that it requires active
involvement to get hooked into the last call discussion...

- Ralph


On 1/15/07 2:37 PM, "Steven M. Bellovin" <[EMAIL PROTECTED]> wrote:


On Mon, 15 Jan 2007 14:26:33 -0500
John C Klensin <[EMAIL PROTECTED]> wrote:



Perhaps we should make it a requirement that any document that
is Last Called must be associated with a mailing list, perhaps
one whose duration is limited to the Last Call period and any
follow-ups until the document is either published or finally
rejected.  If there were a WG, then the WG list should be a
proper subset of that list, anyone commenting during the Last
Call should be added to it, and others could be added on request.


Actually, I think it's an excellent idea.  Tracking Last Call comments
was always difficult, since the email tended to end up in several
different folders and wasn't archived elsewhere.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf