RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Wijnen, Bert (Bert)]

Steve writes:

 Actually, 3683 specifically requires community discussion of motions to 
 block someone's posting rights.  It is, in so many words, done by a 
 Last Call.
 

Steve, I thought that RFC3683 is intended to apply drastic measures
(see intro, page 4).
RFC2418 allows a WG chair and the ADs to also take measures if someone
is disrupting WG progress (sect 3.2).

I certainly hope that we do not have to have the equivalent of an
IETF Last Call everytime that a WG chair or AD finds that an individual
is disrupting normal WG process.

Bert

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

RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Nick Staff]

Bert,

David asked the IESG to consider a PR-action (posting rights action)
against Dean.  Posting rights actions are governed by RFC 3683.

I agree that 3683 is used to apply drastic measures, but unfortunately those
are the measures the AD saw as appropriate for Dean's supposed infractions.
Even the RFC refers to applicable cases as serious situations, but again
it was the AD who thought it fair to levy the harshest sentence at our
disposal against Dean.  It's judgment calls like that which make everything
circumspect to me.

nick

 -Original Message-
 From: Wijnen, Bert (Bert) [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, September 27, 2005 2:01 AM
 To: Steven M. Bellovin; [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; 'IESG'; ietf@ietf.org
 Subject: RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list] 
 
 Steve writes:
 
  Actually, 3683 specifically requires community discussion 
 of motions 
  to block someone's posting rights.  It is, in so many 
 words, done by a 
  Last Call.
  
 
 Steve, I thought that RFC3683 is intended to apply drastic measures
 (see intro, page 4).
 RFC2418 allows a WG chair and the ADs to also take measures 
 if someone is disrupting WG progress (sect 3.2).
 
 I certainly hope that we do not have to have the equivalent 
 of an IETF Last Call everytime that a WG chair or AD finds 
 that an individual is disrupting normal WG process.
 
 Bert
 


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

Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[John Leslie]

Wijnen, Bert (Bert) [EMAIL PROTECTED] wrote:
 
 I certainly hope that we do not have to have the equivalent of an
 IETF Last Call everytime that a WG chair or AD finds that an individual
 is disrupting normal WG process.

   RFC 3683 (BCP 83) is concise enough to quote the applicable part in
its entirety:
] 
]A PR-action identifies one or more individuals, citing messages
]  posted by those individuals to an IETF mailing list, that appear to
]  be abusive of the consensus-driven process.  If approved by the IESG,
]  then:
] 
]  o  those identified on the PR-action have their posting rights to
] that IETF mailing list removed; and,
] 
]  o  maintainers of any IETF mailing list may, at their discretion,
] also remove posting rights to that IETF mailing list.
] 
]  Once taken, this action remains in force until explicitly nullified
]  and SHOULD remain in force for at least one year.
] 
]  One year after the PR-action is approved, a new PR-action MAY be
]  introduced which restores the posting rights for that individual.
]  The IESG SHOULD consider the frequency of nullifying requests when
]  evaluating a new PR-action.  If the posting rights are restored the
]  individual is responsible for contacting the owners of the mailing
]  lists to have them restored.
] 
]  Regardless of whether the PR-action revokes or restores posting
]  rights, the IESG follows the same algorithm as with its other
]  actions:
] 
]  1.  it is introduced by an IESG Area Director (AD), who, prior to
]  doing so, may choose to inform the interested parties;
] 
]  2.  it is published as an IESG last call on the IETF general
]  discussion list;
] 
]  3.  it is discussed by the community;
] 
]  4.  it is discussed by the IESG; and, finally,
] 
]  5.  using the usual consensus-based process, it is decided upon by
]  the IESG.
] 
]  Of course, as with all IESG actions, the appeals process outlined in
]  [4] may be invoked to contest a PR-action approved by the IESG.
] 
]  Working groups SHOULD ensure that their associated mailing list is
]  manageable.  For example, some may try to circumvent the revocation
]  of their posting rights by changing email addresses; accordingly it
]  should be possible to restrict the new email address.

   A PR-action under BC 83 is intended to be permanent. I certainly
hope we _do_ have an IETF Last Call every time a WGC feels the need
to _permanently_ revoke posting rights.

 RFC2418 allows a WG chair and the ADs to also take measures if someone
 is disrupting WG progress (sect 3.2).
] 
] As with face-to-face sessions occasionally one or more individuals
] may engage in behavior on a mailing list which disrupts the WG's
] progress.  In these cases the Chair should attempt to discourage the
] behavior by communication directly with the offending individual
] rather than on the open mailing list.  If the behavior persists then
] the Chair must involve the Area Director in the issue.  As a last
] resort and after explicit warnings, the Area Director, with the
] approval of the IESG, may request that the mailing list maintainer
] block the ability of the offending individual to post to the mailing
] list.

   This looks similar, but it does not require the one-year minimum,
nor does it require a LastCall.

   Furthermore, this _has_been_done_ for Dean Anderson on dnsops.
From the IESG minutes of 13 May 2004:
] 
] 7.2 Approval to block participant on a WG list (Bert Wijnen)
] 
] This management issue was discussed.  The IESG agrees that Bert 
] Wijnen may block posting rights for Dean Anderson on the dnsops 
] mailing list if he refuses to stay on topic as per the list rules.

which raises the question, Why are we even discussing this?

--
John Leslie [EMAIL PROTECTED]

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

RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Nick Staff]

 
 Wijnen, Bert (Bert) [EMAIL PROTECTED] wrote:
  
  I certainly hope that we do not have to have the equivalent of an 
  IETF Last Call everytime that a WG chair or AD finds that an 
  individual is disrupting normal WG process.
 
RFC 3683 (BCP 83) is concise enough to quote the 
 applicable part in its entirety:
 ] 
 ]A PR-action identifies one or more individuals, citing messages
 ]  posted by those individuals to an IETF mailing list, that 
 appear to ]  be abusive of the consensus-driven process.  If 
 approved by the IESG, ]  then:
 ]
 ]  o  those identified on the PR-action have their posting rights to
 ] that IETF mailing list removed; and,
 ]
 ]  o  maintainers of any IETF mailing list may, at their discretion,
 ] also remove posting rights to that IETF mailing list.
 ]
 ]  Once taken, this action remains in force until explicitly 
 nullified ]  and SHOULD remain in force for at least one year.
 ]
 ]  One year after the PR-action is approved, a new PR-action 
 MAY be ]  introduced which restores the posting rights for 
 that individual.
 ]  The IESG SHOULD consider the frequency of nullifying 
 requests when ]  evaluating a new PR-action.  If the posting 
 rights are restored the ]  individual is responsible for 
 contacting the owners of the mailing ]  lists to have them restored.
 ]
 ]  Regardless of whether the PR-action revokes or restores 
 posting ]  rights, the IESG follows the same algorithm as 
 with its other ]  actions:
 ]
 ]  1.  it is introduced by an IESG Area Director (AD), who, prior to
 ]  doing so, may choose to inform the interested parties;
 ]
 ]  2.  it is published as an IESG last call on the IETF general
 ]  discussion list;
 ]
 ]  3.  it is discussed by the community; ] ]  4.  it is 
 discussed by the IESG; and, finally, ] ]  5.  using the usual 
 consensus-based process, it is decided upon by
 ]  the IESG.
 ]
 ]  Of course, as with all IESG actions, the appeals process 
 outlined in ]  [4] may be invoked to contest a PR-action 
 approved by the IESG.
 ]
 ]  Working groups SHOULD ensure that their associated mailing 
 list is ]  manageable.  For example, some may try to 
 circumvent the revocation ]  of their posting rights by 
 changing email addresses; accordingly it ]  should be 
 possible to restrict the new email address.
 
A PR-action under BC 83 is intended to be permanent. I 
 certainly hope we _do_ have an IETF Last Call every time a 
 WGC feels the need
 to _permanently_ revoke posting rights.
 
  RFC2418 allows a WG chair and the ADs to also take measures 
 if someone 
  is disrupting WG progress (sect 3.2).
 ]
 ] As with face-to-face sessions occasionally one or more 
 individuals ] may engage in behavior on a mailing list which 
 disrupts the WG's ] progress.  In these cases the Chair 
 should attempt to discourage the ] behavior by communication 
 directly with the offending individual ] rather than on the 
 open mailing list.  If the behavior persists then ] the Chair 
 must involve the Area Director in the issue.  As a last ] 
 resort and after explicit warnings, the Area Director, with 
 the ] approval of the IESG, may request that the mailing list 
 maintainer ] block the ability of the offending individual to 
 post to the mailing ] list.
 
This looks similar, but it does not require the one-year 
 minimum, nor does it require a LastCall.
 
Furthermore, this _has_been_done_ for Dean Anderson on dnsops.
 From the IESG minutes of 13 May 2004:
 ]
 ] 7.2 Approval to block participant on a WG list (Bert 
 Wijnen) ] ] This management issue was discussed.  The IESG 
 agrees that Bert ] Wijnen may block posting rights for Dean 
 Anderson on the dnsops ] mailing list if he refuses to stay 
 on topic as per the list rules.
 
 which raises the question, Why are we even discussing this?
 
 --
 John Leslie [EMAIL PROTECTED]
 
John-

Could you please specify the RFC that details the procedure for when an AD
requests that the IESG remove someone's posting privileges from the IETF
list (the RFC other 3683 of course).  If there isn't one then I'd have to
ask that you refrain from making wildly unsupported claims as they are
disruptive to the process.

Thanks,
Nick


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

Re: [Int-area] RE: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e)Networks]

[Spencer Dawkins]

Could we pick one of the six mailing lists to discuss this BOF? :-)

I'm guessing int-area would be appropriate - any counterexamples?

Thanks,

Spencer


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of ext Soohong Daniel Park

Sent: 27 September, 2005 02:09
To: IPv6 WG; IPv6-Ops Area; Int-area ML; IETF ML; MIPSHOP WG; MIP6 WG
Cc: [EMAIL PROTECTED]
Subject: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks]

Folks,

We would like to announce a BoF at the upcoming IETF, leading 
to identify what limitations and considerations apply to IPv6 
adoption over IEEE 802.16(e), and to propose available 
solutions. A mailing list is set up at 
[EMAIL PROTECTED] and a proposed description is below.


==

IPv6 over IEEE 802.16(e) Networks BoF (16ng)


CHAIRS:

Soohong Daniel Park[EMAIL PROTECTED] Gabriel 
Montenegro[EMAIL PROTECTED]



DESCRIPTION:

Broadband Wireless Access Network addresses the inadequacies 
of low bandwidth wireless communication for user requirements 
such as high quality data/voice service, fast mobility, wide 
coverage, etc. The IEEE 802.16 Working Group on Broadband 
Wireless Access Standards develops standards and recommended 
practices to support the development and deployment of 
broadband Wireless Metropolitan Area Networks. In addition, 
IEEE 802.16e supports mobility over IEEE 802.16 as an 
amendment to the IEEE 802.16 specification. 

Recently, much work is in progress by the WiMAX Forum. In 
particular, its NWG (Network Working Group) is responsible for 
the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6, 
Mobility, Interworking with different networks, AAA, etc). The 
NWG is thus taking on work at layers above those defined by 
the IEEE 802 standards (typically limited to the physical and 
link layers only). Similarly, WiBro (Wireless Broadband) is a 
Korean effort based on the IEEE 802.16e specification which 
focuses on the 2.3 GHz spectrum band.


IEEE 802.16(e) is different from existing wireless access 
technologies such as  IEEE 802.11 or 3G. Accordingly, the use 
of IP over an IEEE 802.16(e) link is currently undefined, and 
will benefit from IETF input and specification. For example, 
even though Neighbor Discovery has been specified to work over 
point-to-point type links (e.g., as available in 3G), it 
applies most naturally to link technologies capable of native 
multicasing. Thus, it is not yet clear how it would work over 
IEEE 802.16(e) networks. Even though these supports a PMP 
(Point-to-Multipoint) mode, there is no provision for 
multicasting IP packets, hindering the basic standard IPv6 
operation. An IEEE 802.16(e) connection for IP packet transfer 
is a point-to-point unidirectional mapping between medium 
access control layers at the ubscriber station and the base 
station. This eventually requires convergence protocols to 
emulate the desired service on network entities such as base 
stations, which may limit IPv6 features. As for fast mobility, 
the characteristics of IEEE 802.16e link-layer operation may 
require an amendment to the Fast Handover Mobile IPv6 scheme 
(RFC 4068), something which may be pursued in the MIPSHOP WG.


The principal objective of the 16ng BoF is to identify what 
limitations and considerations apply to IPv6 adoption over 
IEEE 802.16(e), and to propose available solutions. The 
working group may issue recommendations to IEEE 802.16(e) 
suggesting protocol modifications for better IP support. 

In 2006, WiBro deployment will begin, and the WiMAX Forum is 
slated to specify IPv6 operation over IEEE 802.16(e) in 2006. 
Accordingly, the working group will work and coordinate with 
the WiMAX Forum and with the WiBro efforts.



MAILING LIST: 

General Discussion: [EMAIL PROTECTED] To Subscribe: 
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
Archive: http://eeca16.sogang.ac.kr/pipermail/16ng 



REFERENCES:

http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt
http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802.
16-00.txt
http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt 
IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon) 



Regards,

Gabriel  Daniel 
16ng BoF co-chairs




___
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area

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

Re: [Mip6] RE: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks]

[장희진]

The first goal might be to run IPv6 basic operation over 802.16/(e).
Additionally, based on that, the interaction betwwen 802.16e and IPv6 for the 
seamless IPv6 mobility could fall in the scope as written in the charter. :)

-from a part of the charter -
As for fast mobility, the characteristics of IEEE 802.16e link-layer operation 
may require an amendment to the Fast Handover Mobile IPv6 scheme (RFC 4068), 
something which may be pursued in the MIPSHOP WG.


- Original Message - 

General question - I know that the WiMax forum is working on more things
than just IP over 802-16e (etc.).  You mention, for example, AAA, in the
description.  Are you looking at more than just running IP over 802.16e
or something more?

John 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of ext Soohong Daniel Park
Sent: 27 September, 2005 02:09
To: IPv6 WG; IPv6-Ops Area; Int-area ML; IETF ML; MIPSHOP WG; MIP6 WG
Cc: [EMAIL PROTECTED]
Subject: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks]

Folks,

We would like to announce a BoF at the upcoming IETF, leading 
to identify what limitations and considerations apply to IPv6 
adoption over IEEE 802.16(e), and to propose available 
solutions. A mailing list is set up at 
[EMAIL PROTECTED] and a proposed description is below.

==

IPv6 over IEEE 802.16(e) Networks BoF (16ng)


CHAIRS:

Soohong Daniel Park[EMAIL PROTECTED] Gabriel 
Montenegro[EMAIL PROTECTED]


DESCRIPTION:

Broadband Wireless Access Network addresses the inadequacies 
of low bandwidth wireless communication for user requirements 
such as high quality data/voice service, fast mobility, wide 
coverage, etc. The IEEE 802.16 Working Group on Broadband 
Wireless Access Standards develops standards and recommended 
practices to support the development and deployment of 
broadband Wireless Metropolitan Area Networks. In addition, 
IEEE 802.16e supports mobility over IEEE 802.16 as an 
amendment to the IEEE 802.16 specification. 

Recently, much work is in progress by the WiMAX Forum. In 
particular, its NWG (Network Working Group) is responsible for 
the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6, 
Mobility, Interworking with different networks, AAA, etc). The 
NWG is thus taking on work at layers above those defined by 
the IEEE 802 standards (typically limited to the physical and 
link layers only). Similarly, WiBro (Wireless Broadband) is a 
Korean effort based on the IEEE 802.16e specification which 
focuses on the 2.3 GHz spectrum band.

IEEE 802.16(e) is different from existing wireless access 
technologies such as  IEEE 802.11 or 3G. Accordingly, the use 
of IP over an IEEE 802.16(e) link is currently undefined, and 
will benefit from IETF input and specification. For example, 
even though Neighbor Discovery has been specified to work over 
point-to-point type links (e.g., as available in 3G), it 
applies most naturally to link technologies capable of native 
multicasing. Thus, it is not yet clear how it would work over 
IEEE 802.16(e) networks. Even though these supports a PMP 
(Point-to-Multipoint) mode, there is no provision for 
multicasting IP packets, hindering the basic standard IPv6 
operation. An IEEE 802.16(e) connection for IP packet transfer 
is a point-to-point unidirectional mapping between medium 
access control layers at the ubscriber station and the base 
station. This eventually requires convergence protocols to 
emulate the desired service on network entities such as base 
stations, which may limit IPv6 features. As for fast mobility, 
the characteristics of IEEE 802.16e link-layer operation may 
require an amendment to the Fast Handover Mobile IPv6 scheme 
(RFC 4068), something which may be pursued in the MIPSHOP WG.

The principal objective of the 16ng BoF is to identify what 
limitations and considerations apply to IPv6 adoption over 
IEEE 802.16(e), and to propose available solutions. The 
working group may issue recommendations to IEEE 802.16(e) 
suggesting protocol modifications for better IP support. 

In 2006, WiBro deployment will begin, and the WiMAX Forum is 
slated to specify IPv6 operation over IEEE 802.16(e) in 2006. 
Accordingly, the working group will work and coordinate with 
the WiMAX Forum and with the WiBro efforts.

 
MAILING LIST: 

General Discussion: [EMAIL PROTECTED] To Subscribe: 
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
Archive: http://eeca16.sogang.ac.kr/pipermail/16ng 


REFERENCES:

http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt
http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802.
16-00.txt
http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt 
IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon) 


Regards,

Gabriel  Daniel 
16ng BoF co-chairs


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

delegating (portions of) ietf list disciplinary process

[Dave Crocker]

That's the reason the process model delegates handling such problems to 
specific individuals, rather than having all of us, together, participate in 
the review and assessment. 


Actually, 3683 specifically requires community discussion of motions to 
block someone's posting rights.  It is, in so many words, done by a 
Last Call.



I was too cryptic.

Were we only subject to discussion of a 3683 Last Call and were that 
discussion limited to the actual merits of the complaint, we would have very, 
very little ietf list traffic in this realm.


What actually happens is that we get lots of list discussion at each step 
along the way, starting with individual pique at a claimed offense, individual 
pique that someone posted a note stating their individual pique, endless 
discussion about proper process, and endless discussion about abuses of process.


My point about delegation is that it is based on a desire to offload 
some/much/most/all of a task so that the full community is not burdened with 
all of the details.  The difference between the some/much/most/all of course 
depends upon how much of the burden the community wants to retain.


The concept of a public Last Call, for the disciplinary process, suggests that 
only the final stage of the process needs to be fully public.


If we are going to get the desired benefit that comes from delegating things, 
we need to be more selective in what is discussed publicly.  That's not a call 
for censorship.  It is a call for discipline.


For one thing, debating the official details of process requirements should 
almost certainly be taken offline from the IETF list.


For another, individual pique is best pursued either by private exchange or 
through formal complaint.  Neither requires burdening the full IETF list.


d/
--

 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net

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

Procedures for the IETF list (RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list])

[Harald Tveit Alvestrand]

The procedures for management of the IETF list are detailed in RFC 3005 
(the IETF list charter).


Note that there are presently selected IETF sergeants-at-arms.

Harald

--On 27. september 2005 03:58 -0700 Nick Staff [EMAIL PROTECTED] 
wrote:



Could you please specify the RFC that details the procedure for when an AD
requests that the IESG remove someone's posting privileges from the IETF
list (the RFC other 3683 of course).  If there isn't one then I'd have to
ask that you refrain from making wildly unsupported claims as they are
disruptive to the process.






pgpzskQlgA0Fa.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[C. M. Heard]

On Tue, 27 Sep 2005, Nick Staff wrote:
 John-
 
 Could you please specify the RFC that details the procedure for when an AD
 requests that the IESG remove someone's posting privileges from the IETF
 list (the RFC other 3683 of course).  If there isn't one then I'd have to
 ask that you refrain from making wildly unsupported claims as they are
 disruptive to the process.
 
 Thanks,
 Nick

Apparently you missed this in John's message (which you quoted in
its entirety, with garbled formatting):

 RFC2418 allows a WG chair and the ADs to also take measures if someone
 is disrupting WG progress (sect 3.2).
]
] As with face-to-face sessions occasionally one or more individuals
] may engage in behavior on a mailing list which disrupts the WG's
] progress.  In these cases the Chair should attempt to discourage the
] behavior by communication directly with the offending individual
] rather than on the open mailing list.  If the behavior persists then
] the Chair must involve the Area Director in the issue.  As a last
] resort and after explicit warnings, the Area Director, with the
] approval of the IESG, may request that the mailing list maintainer
] block the ability of the offending individual to post to the mailing
] list.

Look on the second paragraph on Page 13.

//cmh


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

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Robert Elz]

Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
From:Dean Anderson [EMAIL PROTECTED]
Message-ID:  [EMAIL PROTECTED]

  | It is not DNSSEC that is broken.

I have not been following dnsop discussions, but from this summary, there
is nothing broken beyond your understanding of what is happening.

  | Without getting into to much detail, Anycast doesn't work with TCP, 
  | but it also doesn't work with large UDP packets and fragments.

Anycast does not work (or perhaps more correctly, in some circumstances
when there is routing instability, will not work) with fragmented UDP packets
(the size of the packets is irrelevant, only whether they are fragmented),
when sending those fragments *to* an anycast address.

  | DNSSEC requires large UDP packets and fragments.

DNSSEC might send large UDP packets, which might be fragmented, from the
server answering a query.   A query itself will not be noticeably bigger
than it was without DNSSEC (and that is generally much smaller any reasonable
MTU).

We send queries to the root servers, and receive answers from them.
An anycast address at the root server cannot possibly have any noticeable
effect upon DNSSEC UDP.

  | Your assumption below is common: You assume that everyone does course
  | grained load balancing or no load balancing.

It is irrelevant what *everyone* does - only what the root nameservers do.

It is anycast at the root name servers that you seem to be complaining about.
If the root servers are going fine grained load balancing, then it would not
only be routing instability that would result in a switch of server.   I am
by no means convinced that even that would be any kind of a serious problem
for the root servers (or those sending legitimate queries to them - they
should not be receiving large queries, and should never be sent a query via
TCP under any circumstances - unless they send you a reply with TC set, and
I doubt the root servers are going to start doing that).

But which of the root servers are doing fine grained load balancing using
anycast that way?   And why would they even consider that?   Spreading
root servers around the globe, using anycast (coarse grained anycast) makes
lots of sense, load balancing amongst several servers on the same cable
(that is, near the end of the same path) makes almost none.

Now, if you, the client, are using anycast, and you're sending DNS queries
from what is effectively an anycast address, then you're likely to have
all kinds of problems.   But that's your problem, no-one else's.


But, even assume that there was some validity in your argument (which there
isn't), the way to make it, would be something more like what you have in the
message I am replying to. Note in this message there was no mention of ISC,
and no hints at some kind of conspiracy by anyone to do something with which
you disagree, and somehow sneak it in everywhere without your permission
(though why anyone would need that I fail to see either).   It was that
part of your messages which is what I assume was objected to, plus, quite
probably, your seeming willingness to keep on making the same invalid
argument over and over, even though you're convincing no-one who can see
past the volume.

If you want to make what you believe is a valid technical argument, make
just that, and leave out the name calling.   That is, if you're ever
allowed back onto the dnsop list in the first place.

Finally, just for your information - the IETF does not control the root
nameservers, and never has, and nothing the IETF says or does has any more
than an advisory impact upon how they operate.

kre


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

Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Steven M. Bellovin]

In message [EMAIL PROTECTED], Nick Staff writes:

 ]
 ] 7.2 Approval to block participant on a WG list (Bert 
 Wijnen) ] ] This management issue was discussed.  The IESG 
 agrees that Bert ] Wijnen may block posting rights for Dean 
 Anderson on the dnsops ] mailing list if he refuses to stay 
 on topic as per the list rules.
 
 which raises the question, Why are we even discussing this?
 
 --
 John Leslie [EMAIL PROTECTED]
 
John-

Could you please specify the RFC that details the procedure for when an AD
requests that the IESG remove someone's posting privileges from the IETF
list (the RFC other 3683 of course).  If there isn't one then I'd have to
ask that you refrain from making wildly unsupported claims as they are
disruptive to the process.


Have a look at 3934.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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

RE: delegating (portions of) ietf list disciplinary process

[Hallam-Baker, Phillip]

 Behalf Of Dave Crocker

 For another, individual pique is best pursued either by 
 private exchange or 
 through formal complaint.  Neither requires burdening the 
 full IETF list.

I disagree, hard cases make bad law, good cases make bad procedure. It
is easy to see why process is unnecessary in good cases. It's the bad
ones where there is a problem.

Recently an IRTF WG chair decided to effectively turn the group into a
publicity engine for his own company and banned anyone who objected to
this or disagreed with him, at one point he had banned about a third of
the active members. He is no longer the chair and the normal process
took its course but what would have happened if there had been no open
process?

The point is that we cannot assume that WG chairs always operate in good
faith and that any objections that appear on the lists are from cranks
despite the simplicity that model provides. 

WG chairs are not elected, the ADs are not elected. The accountability
processes of the IETF are not designed for the type of action suggested.
If the consensus processes are blocked then complaints are more likely
to end up being littigated rather than thrashed out in public.


My objection to this thread is that people appear to have rushed to
judgement that this is a disciplinary issue before considering the
substance of the point raised. People seem to be saying that there is no
time to read the message because they are too busy shooting the
messenger.

I do not understand the objection that Dean is raising, I certainly do
not see that a defect in DNSSEC should constrain DNS operations. However
I will point out that four years ago we had a similar argument about a
defect in DNSSEC that I predicted would prevent deployment in the major
TLDs for at least five years. The procedural abuses that took place in
that instance have resulted in the current situation where phishing is a
real problem and there is justified concern that DNS based attacks -
pharming will become a threat.


There is a simple way to settle this issue, state that it is a
requirement for DNSSEC to work with anycast. This is not impossible to
achieve, an RSA signature is only 256 bytes, a DNS response can be 500
bytes without difficulty and in practice can be up to the ethernet MTA
of 1400 bytes without significant operational issues. A response from a
TLD is small. I don't see why packet fragmentation would be a problem
for the anycast TLDs.

 

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

RE: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Hallam-Baker, Phillip]

 From: Dean Anderson [mailto:[EMAIL PROTECTED] 

 It is not DNSSEC that is broken.

Anycast has been deployed for four years. Any change to the DNS
infrastructure that is incompatible with use of anycast is not
acceptable and will not be deployed.

Anycast significantly improves the response time and the robustness of
DNS operations and allows operations to be made more scalable and run
more economically. 

Core DNS is subject to continuous DDoS attacks. Without anycast there is
a possibility that at some point in the future it might not be possible
to support the bandwidth needed to defeat these attacks.

The DNS has operated successfully without DNSSEC up to this point. The
onus is always on those proposing a change to work within the deployed
infrastructure.

The DNSSEC spec makes several proposals that appear to address the
packet fragmentation issue. If you think these are inadequate you should
explain why.

Phill

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

Re: delegating (portions of) ietf list disciplinary process

[Brian E Carpenter]

I'm interested to know whether people would see arguments for
either or both of

1. An IETF Ombudsman (or Ombudscommittee), to act as a dispute
mediator.

2. An IETF netiquette committee, to offload list banning procedures
from the IESG.

Brian

Dave Crocker wrote:


That's the reason the process model delegates handling such problems 
to specific individuals, rather than having all of us, together, 
participate in the review and assessment. 



Actually, 3683 specifically requires community discussion of motions 
to block someone's posting rights.  It is, in so many words, done by a 
Last Call.




I was too cryptic.

Were we only subject to discussion of a 3683 Last Call and were that 
discussion limited to the actual merits of the complaint, we would have 
very, very little ietf list traffic in this realm.


What actually happens is that we get lots of list discussion at each 
step along the way, starting with individual pique at a claimed offense, 
individual pique that someone posted a note stating their individual 
pique, endless discussion about proper process, and endless discussion 
about abuses of process.


My point about delegation is that it is based on a desire to offload 
some/much/most/all of a task so that the full community is not burdened 
with all of the details.  The difference between the 
some/much/most/all of course depends upon how much of the burden the 
community wants to retain.


The concept of a public Last Call, for the disciplinary process, 
suggests that only the final stage of the process needs to be fully public.


If we are going to get the desired benefit that comes from delegating 
things, we need to be more selective in what is discussed publicly.  
That's not a call for censorship.  It is a call for discipline.


For one thing, debating the official details of process requirements 
should almost certainly be taken offline from the IETF list.


For another, individual pique is best pursued either by private exchange 
or through formal complaint.  Neither requires burdening the full IETF 
list.


d/



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

Re: delegating (portions of) ietf list disciplinary process

[Marshall Eubanks]

Dear Brian;

On Tue, 27 Sep 2005 17:15:05 +0200
 Brian E Carpenter [EMAIL PROTECTED] wrote:
 I'm interested to know whether people would see arguments for
 either or both of
 
 1. An IETF Ombudsman (or Ombudscommittee), to act as a dispute
 mediator.
 
 2. An IETF netiquette committee, to offload list banning procedures
 from the IESG.
 

I would support this. I suspect that suggestion number 1 might be most 
appropriate.

These cases are going to be tough, and an outside review with some measure of 
independence from the
system will be necessary to be seen as fair. For example, in the original email 
of David Kessens,
which contained a mail thread of abusive mail, the trouble to me was that no 
one of those
emails contained anything I would regard as abusive. The trouble is that the 
abuse (if any) is in
the pattern over time, not what's said at any one time.

I remember back in 1997 or so being on a working group mailing list that was 
subject to the
attentions of the Alternic and IPv8 crowd. While their posts were mostly 
polite, the shear number of
them, and the way that things could go off on total tangents did represent a 
DOS. (Frankly, the
words Chinese Water Torture come to mind.) Once you've been subjected to 
something like that for a
while, there is a real danger of over-reaction, banning people just because 
they innocently bring up
a sensitive topic. And, of course, it may be hard to convince people you are 
being fair no matter
what you do, if there is no one email you can point  to as evidence.

So I think that intrinsic to fairly treating this problem is a need to convince 
someone on the
outside of the reality of the perceived abuse. If the offender consistently 
(say) calls someone rude
names, that is easy, and  can  be done (say) on this list. If the abuse 
consists of a pattern of
email traffic over time, then someone will have to at least dip into the stream 
and read it, and
that (to me) suggests an Ombudsman. In the case that engendered this 
discussion, for example, I see
no outwardly abusive emails of the name-calling variety, but neither do I feel 
the inclination to
read a few months of back traffic for the relevant WG's. In the best Scottish 
tradition, I would
therefore have to return a verdict of not proven, and would feel happier if 
there was a report
from an outside party.

If there is to be a committee, I would suggest that it be formed randomly from 
volunteers who  hold
no other posts, in the NomCom fashion.

Regards
Marshall

  Brian
 
 Dave Crocker wrote:
  
  That's the reason the process model delegates handling such problems 
  to specific individuals, rather than having all of us, together, 
  participate in the review and assessment. 
 
 
  Actually, 3683 specifically requires community discussion of motions 
  to block someone's posting rights.  It is, in so many words, done by a 
  Last Call.
  
  
  
  I was too cryptic.
  
  Were we only subject to discussion of a 3683 Last Call and were that 
  discussion limited to the actual merits of the complaint, we would have 
  very, very little ietf list traffic in this realm.
  
  What actually happens is that we get lots of list discussion at each 
  step along the way, starting with individual pique at a claimed offense, 
  individual pique that someone posted a note stating their individual 
  pique, endless discussion about proper process, and endless discussion 
  about abuses of process.
  
  My point about delegation is that it is based on a desire to offload 
  some/much/most/all of a task so that the full community is not burdened 
  with all of the details.  The difference between the 
  some/much/most/all of course depends upon how much of the burden the 
  community wants to retain.
  
  The concept of a public Last Call, for the disciplinary process, 
  suggests that only the final stage of the process needs to be fully public.
  
  If we are going to get the desired benefit that comes from delegating 
  things, we need to be more selective in what is discussed publicly.  
  That's not a call for censorship.  It is a call for discipline.
  
  For one thing, debating the official details of process requirements 
  should almost certainly be taken offline from the IETF list.
  
  For another, individual pique is best pursued either by private exchange 
  or through formal complaint.  Neither requires burdening the full IETF 
  list.
  
  d/
 
 
 ___
 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: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[wayne]

In [EMAIL PROTECTED] Robert Elz [EMAIL PROTECTED] writes:

   | Without getting into to much detail, Anycast doesn't work with TCP, 
   | but it also doesn't work with large UDP packets and fragments.

 Anycast does not work (or perhaps more correctly, in some circumstances
 when there is routing instability, will not work) with fragmented UDP packets
 (the size of the packets is irrelevant, only whether they are fragmented),
 when sending those fragments *to* an anycast address.

In order for anycast DNS to fail, either due to the use of TCP or in
cases where the UDP DNS query was fragmented, doesn't the network
routing instability have to be such that retries also fail?  A single
failure isn't fatal, after all.  The routes would have to be flapping
pretty badly to most of the root servers (anycast or not) for this to
cause any problems, in which case, I think we would be far more
worried about other things.


 It is anycast at the root name servers that you seem to be complaining about.
 If the root servers are going fine grained load balancing, then it would not
 only be routing instability that would result in a switch of server.   I am
 by no means convinced that even that would be any kind of a serious problem
 for the root servers (or those sending legitimate queries to them [...]

I'm not sure I see any problem at all here, serious or not.  Even if a
root server is doing fine grained load balancing, all the packets will
still end up at the destination address, where fragments can be
reassembled and out of order reception can be resolved.


 Now, if you, the client, are using anycast, and you're sending DNS queries
 from what is effectively an anycast address, then you're likely to have
 all kinds of problems.   But that's your problem, no-one else's.

Yeah, I can't see how a DNS client could work as an anycast
destination.  Getting an answer on a machine that you didn't send the
query from isn't going to be very useful.



This is all theoretical arguing and theory is different than
practice.

Can someone show an actual case where the use of anycast DNS servers
cause problems?  Using standard commands like dig or nslookup would be
best, but even if you have to create a specialized DNS client and/or
server, that would make any real problems much clearer.  I'm not
looking for rock solid, can-not-get-around examples even, just like I
don't think you need to show that a buffer overrun can actually cause
an exploit.  Just a proof of concept will do.

Right now, it looks like in theory, the use of anycast DNS servers
can't be a significant problem.  So far, I have seen no demonstrations
of practical problems. To the best of my understanding, this has been
the state of the debate for years now.


This looks like a tempest in a teapot to me.


-wayne


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

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Bill Sommerfeld]

On Tue, 2005-09-27 at 10:06, Robert Elz wrote:
 Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
 From:Dean Anderson [EMAIL PROTECTED]
 Message-ID:  [EMAIL PROTECTED]
 
   | It is not DNSSEC that is broken.
 
 I have not been following dnsop discussions, but from this summary, there
 is nothing broken beyond your understanding of what is happening.

It's worse.  The reasoning is broken on other points, as well.

In these arguments, RFC 1812 has been cited repeatedly as a
specification for load-splitting.  By my reading, 1812 is extremely
vague about the topic, and does not require a specific spreading
algorithm.  Its strongest recommendation is that there be a way to turn
it off if it doesn't work for you, which should by itself be a clue that
load-spreading should be used with caution; it also cautions that that
load-splitting was an area of active research at the time 1812 was
published.

Moreover, load-splitting which results in the sort of flow-shredding
which would disrupt multi-packet anycast exchanges also causes
significant difficulties for unicast.  To quote from rfc2991 section 2:

   Several router implementations allow multipath forwarding.  This is
   sometimes done naively via round-robin, where each packet matching a
   given destination route is forwarded using the subsequent next-hop,
   in a round-robin fashion.  This does provide a form of load
   balancing, but there are several problems with approaches such as
   round-robin or random:

   Variable Path MTU
 Since each of the redundant paths may have a different MTU,
 this means that the overall path MTU can change on a packet-
 by-packet basis, negating the usefulness of path MTU discovery.

   Variable Latencies
 Since each of the redundant paths may have a different latency
 involved, having packets take separate paths can cause packets
 to always arrive out of order, increasing delivery latency and
 buffering requirements.

 Packet reordering causes TCP to believe that loss has taken
 place when packets with higher sequence numbers arrive before
 an earlier one.  When three or more packets are received before
 a late packet, TCP enters a mode called fast-retransmit [6]
 which consumes extra bandwidth (which could potentially cause
 more loss, decreasing throughput) as it attempts to
 unnecessarily retransmit the delayed packet(s).  Hence,
 reordering can be detrimental to network performance.

   Debugging
 Common debugging utilities such as ping and traceroute are much
 less reliable in the presence of multiple paths and may even
 present completely wrong results.

And folks I know who build gear which does load-splitting seem to be
scrupulously careful to avoid these sorts of problems. 

- Bill





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

IPR Trust - draft-carpenter-bcp101-update-02 and the IASA

[John C Klensin]

Brian,

This is a fine document.  Perhaps appropriately, it doesn't say 
much of anything.


Is the actual trust agreement a secret, or does the IETF and 
IASA intend to make it public before the IESG approves it?  Will 
there be an IETF Last Call that includes an opportunity to 
review the document itself?


I note that the IASA web pages don't mention this at all except 
for a paragraph under Draft Agreements.  That says



Proposed IPR Trust
The IAOC received on May 5th a new draft Trust Agreement from
CNRI and is in the process of preparing a response. The IAOC
expects that a revised Trust Agreement will be sent to CNRI in
early June


And is presumably a bit out of date, given comments in the 
monthly report you circulated.   And, referring to that report, 
it also discusses new draft engagement agreements with Counsel 
and other draft agreements which are not mentioned on the IASA 
web site, much less available there.


I am sure all of this is fine, but the agreement with the 
community when IASA was formed was that all of these things 
would be public to the extent possible.  To the extent to which 
few or none of them appear to be available, and the IASA/IAOC 
does not seem to be able to keep its own web pages current and 
the community informed that way, rather than via just overview 
monthly reports, I think it should be a matter of concern to all 
of us.


   john





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

Update on the IPR Trust

[Lucy E. Lynch]

All -

As I outlined in my presentation at IETF 63*, the IAOC is pursuing the
notion of a dedicated IPR Trust. We have been through several revisions of
the Trust document and have developed a formula that we believe will work
for all parties. Below you'll find a summary of the current framework for
such a trust. The IAOC believes that the formation of such a Trust is in
the best interests of the IETF as a whole and we hope to close on a final
document in the near future. Please send comments or questions to:
[EMAIL PROTECTED]

*(http://koi.uoregon.edu/~iaoc/116.html)

IETF IPR Trust Summary: __

The IETF Trust will be created by ISOC, CNRI and the IETF. Its purposes
include acquiring, holding, maintaining and licensing certain existing and
future intellectual property used in connection with the Internet
standards process. The Beneficiary of the Trust shall be the IETF as a
whole.

ISOC and CNRI, as settlors, will transfer to the Trust all of their right,
title and interest, if any, in and to their respective IPR relevant to the
IETF [specified below]. The Trustees will encourage others who may hold
rights and interests in intellectual property, domain names or other
property relevant to the IETF to similarly transfer all of their
respective rights, title and interest therein to the Trust.

The Trustees will be the members of the IAOC.

The Trust shall be for an indefinite term (limited to the maximum period
permitted by law). Prior to July 1, 2010, the Trust Agreement may be
amended only by unanimous written consent of ISOC and CNRI and two-thirds
of the Trustees. After July 1, 2010, the Trustees, acting by at least a
two-thirds majority vote, may elect to amend or terminate the Trust.

The Trust (acting through the Trustees) shall have the right to grant
licenses for the use of the Trust Assets on such terms, as the Trustees
deem appropriate; provided, however, that the Trust shall not grant any
license that would be deemed a transfer of ownership or abandonment of any
Trust Assets under applicable law.

Initial contributed IPR shall be (as far as the parties' rights extend):

-   Trademarks
-   Domain names
-   Current databases, mailing lists, web pages, working group
and IESG materials
-   Current I-Ds and RFCs
-   Rights in extracted historical data (records of past meetings,
 past I-Ds and RFCs and their processing history)
__
Lucy E. Lynch   Academic User Services
Computing CenterUniversity of Oregon
llynch  @darkwing.uoregon.edu   (541) 346-1774

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

Re: IPR Trust - draft-carpenter-bcp101-update-02 and the IASA

[Lucy E. Lynch]

On Tue, 27 Sep 2005, John C Klensin wrote:

 Brian,

 This is a fine document.  Perhaps appropriately, it doesn't say
 much of anything.

 Is the actual trust agreement a secret, or does the IETF and
 IASA intend to make it public before the IESG approves it?  Will
 there be an IETF Last Call that includes an opportunity to
 review the document itself?

The actual document is still in review and and the on-going discussions
are privileged as they invole outside parties. I've just sent a summary of
our framework to the list (you anticipated me by a few minutes). The
document falls under the contracts or equivalent instruments with outside
organizations and IPR related duties of the IASA as outlined in section 3
of BCP 101 and as I understand this section is not subject to IETF Last
Call. We are making our best efforts to relay information as it becomes
available.

 I note that the IASA web pages don't mention this at all except
 for a paragraph under Draft Agreements.  That says

  Proposed IPR Trust
  The IAOC received on May 5th a new draft Trust Agreement from
  CNRI and is in the process of preparing a response. The IAOC
  expects that a revised Trust Agreement will be sent to CNRI in
  early June

See the regular minutes posted here: http://koi.uoregon.edu/~iaoc/2.html

 And is presumably a bit out of date, given comments in the
 monthly report you circulated.   And, referring to that report,
 it also discusses new draft engagement agreements with Counsel
 and other draft agreements which are not mentioned on the IASA
 web site, much less available there.

again, please see the minutes.

 I am sure all of this is fine, but the agreement with the
 community when IASA was formed was that all of these things
 would be public to the extent possible.  To the extent to which
 few or none of them appear to be available, and the IASA/IAOC
 does not seem to be able to keep its own web pages current and
 the community informed that way, rather than via just overview
 monthly reports, I think it should be a matter of concern to all
 of us.

we are working within the confines of to the extent possible and
hope to be able to share the document soon.

 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: IPR Trust - draft-carpenter-bcp101-update-02 and the IASA

[John C Klensin]

--On Tuesday, September 27, 2005 15:41 -0700 Lucy E. Lynch 
[EMAIL PROTECTED] wrote:



On Tue, 27 Sep 2005, John C Klensin wrote:


Brian,

This is a fine document.  Perhaps appropriately, it doesn't
say much of anything.

Is the actual trust agreement a secret, or does the IETF and
IASA intend to make it public before the IESG approves it?
Will there be an IETF Last Call that includes an opportunity
to review the document itself?


The actual document is still in review and and the on-going
discussions are privileged as they invole outside parties.
I've just sent a summary of our framework to the list (you
anticipated me by a few minutes). The document falls under the
contracts or equivalent instruments with outside
organizations and IPR related duties of the IASA as outlined
in section 3 of BCP 101 and as I understand this section is
not subject to IETF Last Call.


But any new BCP, or modification to a BCP is.  And, whatever the 
negotiations might be that you need to get there, this isn't an 
agreement with an outside organization, it is how IETF IPR is 
managed by the IASA and an IASA-relevant organization.   A claim 
that such a body is outside seems to me to be dubious in the 
extreme.


So, while IASA can probably form the trust in private and tell 
us what has been agreed later, changing the BCP to shift the 
IETF's rights designations from ISOC to something else requires, 
IMO clearly, IETF community approval, just as the decisions to 
shift things _to_ ISOC did.   And whether the community would be 
willing to agree to the draft Brian posted without being able to 
see _exactly_ how the trust is structured... well, I guess one 
could try to find out.



We are making our best efforts
to relay information as it becomes available.


Understood and appreciated.


I note that the IASA web pages don't mention this at all
except for a paragraph under Draft Agreements.  That says

 Proposed IPR Trust
 The IAOC received on May 5th a new draft Trust Agreement
 from CNRI and is in the process of preparing a response.
 The IAOC expects that a revised Trust Agreement will be
 sent to CNRI in early June


See the regular minutes posted here:
http://koi.uoregon.edu/~iaoc/2.html


And is presumably a bit out of date, given comments in the
monthly report you circulated.   And, referring to that
report, it also discusses new draft engagement agreements
with Counsel and other draft agreements which are not
mentioned on the IASA web site, much less available there.


again, please see the minutes.


Lucy, I don't mean to be critical, but the whole IASA 
arrangement was created to provide a strong and easy-to-use 
framework for the community to get it work done.  From my point 
of view at least, that translates into keeping things organized 
enough that the community does not need to read every published 
set of minutes to know what is going on or to find an important 
document.  IASA has professional staff, that staff should either 
be keeping web pages up to date or, IMO, the IAOC has a problem 
which you should be solving on a timely basis, reporting in 
minutes if you can't solve immediately, etc.



I am sure all of this is fine, but the agreement with the
community when IASA was formed was that all of these things
would be public to the extent possible.  To the extent to
which few or none of them appear to be available, and the
IASA/IAOC does not seem to be able to keep its own web pages
current and the community informed that way, rather than via
just overview monthly reports, I think it should be a matter
of concern to all of us.


we are working within the confines of to the extent possible
and hope to be able to share the document soon.


Thank you.
john


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

Re: IPR Trust - draft-carpenter-bcp101-update-02 and the IASA

[Lucy E. Lynch]

On Tue, 27 Sep 2005, John C Klensin wrote:



 --On Tuesday, September 27, 2005 15:41 -0700 Lucy E. Lynch
 [EMAIL PROTECTED] wrote:

  On Tue, 27 Sep 2005, John C Klensin wrote:
 
  Brian,
 
  This is a fine document.  Perhaps appropriately, it doesn't
  say much of anything.
 
  Is the actual trust agreement a secret, or does the IETF and
  IASA intend to make it public before the IESG approves it?
  Will there be an IETF Last Call that includes an opportunity
  to review the document itself?
 
  The actual document is still in review and and the on-going
  discussions are privileged as they invole outside parties.
  I've just sent a summary of our framework to the list (you
  anticipated me by a few minutes). The document falls under the
  contracts or equivalent instruments with outside
  organizations and IPR related duties of the IASA as outlined
  in section 3 of BCP 101 and as I understand this section is
  not subject to IETF Last Call.

 But any new BCP, or modification to a BCP is.  And, whatever the
 negotiations might be that you need to get there, this isn't an
 agreement with an outside organization, it is how IETF IPR is
 managed by the IASA and an IASA-relevant organization.   A claim
 that such a body is outside seems to me to be dubious in the
 extreme.

The Trust is a multi-party document (ISOC/CNRI/IETF) and the modification
to the BCP is meant to reflect a simple change in the putative IPR holder
going forward (from ISOC as defined in BCP101 to the Trust IF such a trust
should be formed). The change moves control of the IPR closer to the
IETF community. I'm not arguing that the Trust, once formed. is outside
but the parties forming the Trust include outside bodies (ISOC and
CNRI).

 So, while IASA can probably form the trust in private and tell
 us what has been agreed later, changing the BCP to shift the
 IETF's rights designations from ISOC to something else requires,
 IMO clearly, IETF community approval, just as the decisions to
 shift things _to_ ISOC did.   And whether the community would be
 willing to agree to the draft Brian posted without being able to
 see _exactly_ how the trust is structured... well, I guess one
 could try to find out.

  We are making our best efforts
  to relay information as it becomes available.

 Understood and appreciated.

  I note that the IASA web pages don't mention this at all
  except for a paragraph under Draft Agreements.  That says
 
   Proposed IPR Trust
   The IAOC received on May 5th a new draft Trust Agreement
   from CNRI and is in the process of preparing a response.
   The IAOC expects that a revised Trust Agreement will be
   sent to CNRI in early June
 
  See the regular minutes posted here:
  http://koi.uoregon.edu/~iaoc/2.html
 
  And is presumably a bit out of date, given comments in the
  monthly report you circulated.   And, referring to that
  report, it also discusses new draft engagement agreements
  with Counsel and other draft agreements which are not
  mentioned on the IASA web site, much less available there.
 
  again, please see the minutes.

 Lucy, I don't mean to be critical, but the whole IASA
 arrangement was created to provide a strong and easy-to-use
 framework for the community to get it work done.  From my point
 of view at least, that translates into keeping things organized
 enough that the community does not need to read every published
 set of minutes to know what is going on or to find an important
 document.  IASA has professional staff, that staff should either
 be keeping web pages up to date or, IMO, the IAOC has a problem
 which you should be solving on a timely basis, reporting in
 minutes if you can't solve immediately, etc.

I'm maintaining the web site as a volunteer. The documents that we can
fully expose are available. We have a number of documents/contacts/etc
that can't be fully exposed (job applications, for example) due to
sensative content or on-going negotiations.

The minutes and the monthly reports are the best tool we have for
giving some insight into our process. They are developed from notes
taken by our volunteer scribe and are posted as they are approved.

  I am sure all of this is fine, but the agreement with the
  community when IASA was formed was that all of these things
  would be public to the extent possible.  To the extent to
  which few or none of them appear to be available, and the
  IASA/IAOC does not seem to be able to keep its own web pages
  current and the community informed that way, rather than via
  just overview monthly reports, I think it should be a matter
  of concern to all of us.
 
  we are working within the confines of to the extent possible
  and hope to be able to share the document soon.

 Thank you.
  john


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

Re: IPR Trust - draft-carpenter-bcp101-update-02 and the IASA

[John C Klensin]

--On Tuesday, September 27, 2005 16:29 -0700 Lucy E. Lynch 
[EMAIL PROTECTED] wrote:



But any new BCP, or modification to a BCP is.  And, whatever
the negotiations might be that you need to get there, this
isn't an agreement with an outside organization, it is how
IETF IPR is managed by the IASA and an IASA-relevant
organization.   A claim that such a body is outside seems
to me to be dubious in the extreme.


The Trust is a multi-party document (ISOC/CNRI/IETF) and the
modification to the BCP is meant to reflect a simple change in
the putative IPR holder going forward (from ISOC as defined in
BCP101 to the Trust IF such a trust should be formed). The
change moves control of the IPR closer to the IETF community.
I'm not arguing that the Trust, once formed. is outside but
the parties forming the Trust include outside bodies (ISOC
and CNRI).


Again, that justifies keeping the agreement private while you 
are negotiating.  I don't question that.  As I understand BCP 
101, you are even entitled to keep such agreements private from 
the IESG and IAB while you are negotiating them, informing those 
bodies and the community only on a need to know basis.  The 
question I was asking was whether the IAOC and/or the IESG 
expected the IETF community to approve a change in the BCP 
without seeing the final trust agreement.  If that answer is 
no, then I think we have a problem since this is a new entity 
that is not intrinsically bound to the same requirements for 
public and open behavior that apply to ISOC and the various IASA 
elements.



  Proposed IPR Trust
  The IAOC received on May 5th a new draft Trust Agreement
  from CNRI and is in the process of preparing a response.
  The IAOC expects that a revised Trust Agreement will be
  sent to CNRI in early June

 See the regular minutes posted here:
 http://koi.uoregon.edu/~iaoc/2.html

...



Lucy, I don't mean to be critical, but the whole IASA
arrangement was created to provide a strong and easy-to-use
framework for the community to get it work done.  From my
point of view at least, that translates into keeping things
organized enough that the community does not need to read
every published set of minutes to know what is going on or to
find an important document.  IASA has professional staff,
that staff should either be keeping web pages up to date or,
IMO, the IAOC has a problem which you should be solving on a
timely basis, reporting in minutes if you can't solve
immediately, etc.


I'm maintaining the web site as a volunteer. The documents
that we can fully expose are available. We have a number of
documents/contacts/etc that can't be fully exposed (job
applications, for example) due to sensative content or
on-going negotiations.


I apologize if this sounds like micromanagement, but, if the 
IASA, which was put together in large measure to move 
administrative tasks from IETF volunteers to professional staff, 
requires you to maintain the web site as a volunteer, then 
something is broken.  That web site and its maintenance is part 
of the administrative function and is required under the IASA 
BCP to keep the IETF community informed.   The IASA staff needs 
to maintain it or make arrangements to keep it current and 
comprehensive, with no excuses.



The minutes and the monthly reports are the best tool we have
for giving some insight into our process. They are developed
from notes taken by our volunteer scribe and are posted as
they are approved.


I probably have the same comment about volunteer scribe that I 
do about volunteer web page.  That is how we used to do 
things, but it is part of the problem the IASA was formed to 
solve.


john


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

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Stephen Sprunk]

Thus spake wayne [EMAIL PROTECTED]
 In [EMAIL PROTECTED] Robert Elz [EMAIL PROTECTED] writes:
  Anycast does not work (or perhaps more correctly, in some
  circumstances when there is routing instability, will not work) with
  fragmented UDP packets (the size of the packets is irrelevant, only
  whether they are fragmented), when sending those fragments *to*
  an anycast address.

 In order for anycast DNS to fail, either due to the use of TCP or in
 cases where the UDP DNS query was fragmented, doesn't the network
 routing instability have to be such that retries also fail?  A single
 failure isn't fatal, after all.  The routes would have to be flapping
 pretty badly to most of the root servers (anycast or not) for this to
 cause any problems, in which case, I think we would be far more
 worried about other things.

The issue is when a network, usually at neither the client nor server end of
the path, uses PPLB such that packets from the same TCP query or fragments
of a single large UDP query will consistently arrive at different anycast
server instances.  The IETF and network operators have long understood that
this is a Bad Thing(tm) in general, and is one of a long list of reasons why
PPLB is strongly discouraged and sees little use today [1].

  It is anycast at the root name servers that you seem to be
  complaining about.  If the root servers are going fine grained load
  balancing, then it would not only be routing instability that would
  result in a switch of server.   I am by no means convinced that even
  that would be any kind of a serious problem for the root servers (or
  those sending legitimate queries to them [...]

 I'm not sure I see any problem at all here, serious or not.  Even if a
 root server is doing fine grained load balancing, all the packets will
 still end up at the destination address, where fragments can be
 reassembled and out of order reception can be resolved.

Anycast in the face of PPLB has been accepted (by most of us, at least)
specifically for the root servers because current queries to the roots do
not need to be fragmented and do not use TCP.

It appears that Dean is alleging that DNSSEC will cause queries to the roots
to be fragmented or to be transmitted over TCP, thus invalidating the
exception which allows root server operators to use anycast.  While I admit
to not having followed the DNSOP list, I've seen no substantiated claims so
far that indicate DNSSEC will cause queries to exceed the minimum MTUs for
IPv4 and/or for IPv6 [2].

 Right now, it looks like in theory, the use of anycast DNS servers
 can't be a significant problem.  So far, I have seen no demonstrations
 of practical problems. To the best of my understanding, this has been
 the state of the debate for years now.

If Dean (or someone else) shows that the above problem case will indeed
occur in real-world situations, the criticism of DNSSEC and/or anycasting is
valid and one of the two needs to be fixed.

 This looks like a tempest in a teapot to me.

Based on the messages to the IETF list so far, it appears so.

For the record, I support a PR action against Dean due to his consistent
provocation of flame wars, particularly as they form a long-term pattern of
harassment of a particular company or persons.  Note that I consider it
irrelevant whether his position in this or any past instance turns out to be
correct: it's the form, not the content, of his efforts that is the problem.

S

[1] Many modern routers, particularly ones used in the Internet core, do not
even have the ability to enable PPLB, and the places where I've seen it used
in the last five years have exclusively been topologies that will always
re-merge the balanced traffic further upstream.
[2] I have seen misguided operators set MTUs below 200 bytes, but my
position is that these people deserve what they get in such cases.  We
cannot cater to deliberately broken implementations.

Stephen SprunkStupid people surround themselves with smart
CCIE #3723   people.  Smart people surround themselves with
K5SSS smart people who disagree with them.  --Aaron Sorkin


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

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[usphoenix]

As a lurker, love him or hate him, Dean does evoke responses as varied 
as any I've observed.  Unfortunately all too often that's the only way 
some truth will be allowed to leak out.  Or people finally put pieces 
together.




-Original Message-
From: Stephen Sprunk [EMAIL PROTECTED]
To: ietf@ietf.org; wayne [EMAIL PROTECTED]
Sent: Tue, 27 Sep 2005 20:09:00 -0500
Subject: Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

 Thus spake wayne [EMAIL PROTECTED]
In [EMAIL PROTECTED] Robert Elz [EMAIL PROTECTED] 

writes:

 Anycast does not work (or perhaps more correctly, in some
 circumstances when there is routing instability, will not work) with
 fragmented UDP packets (the size of the packets is irrelevant, only
 whether they are fragmented), when sending those fragments *to*
 an anycast address.

In order for anycast DNS to fail, either due to the use of TCP or in
cases where the UDP DNS query was fragmented, doesn't the network
routing instability have to be such that retries also fail?  A single
failure isn't fatal, after all.  The routes would have to be flapping
pretty badly to most of the root servers (anycast or not) for this to
cause any problems, in which case, I think we would be far more
worried about other things.


The issue is when a network, usually at neither the client nor server 
end of
the path, uses PPLB such that packets from the same TCP query or 
fragments
of a single large UDP query will consistently arrive at different 
anycast
server instances.  The IETF and network operators have long understood 
that
this is a Bad Thing(tm) in general, and is one of a long list of 
reasons why

PPLB is strongly discouraged and sees little use today [1].


 It is anycast at the root name servers that you seem to be
 complaining about.  If the root servers are going fine grained load
 balancing, then it would not only be routing instability that would
 result in a switch of server.   I am by no means convinced that even
 that would be any kind of a serious problem for the root servers (or
 those sending legitimate queries to them [...]

I'm not sure I see any problem at all here, serious or not.  Even if a
root server is doing fine grained load balancing, all the packets will
still end up at the destination address, where fragments can be
reassembled and out of order reception can be resolved.


Anycast in the face of PPLB has been accepted (by most of us, at least)
specifically for the root servers because current queries to the roots 
do

not need to be fragmented and do not use TCP.

It appears that Dean is alleging that DNSSEC will cause queries to the 
roots

to be fragmented or to be transmitted over TCP, thus invalidating the
exception which allows root server operators to use anycast.  While I 
admit
to not having followed the DNSOP list, I've seen no substantiated 
claims so
far that indicate DNSSEC will cause queries to exceed the minimum MTUs 
for

IPv4 and/or for IPv6 [2].


Right now, it looks like in theory, the use of anycast DNS servers
can't be a significant problem.  So far, I have seen no demonstrations
of practical problems. To the best of my understanding, this has been
the state of the debate for years now.


If Dean (or someone else) shows that the above problem case will indeed
occur in real-world situations, the criticism of DNSSEC and/or 
anycasting is

valid and one of the two needs to be fixed.


This looks like a tempest in a teapot to me.


Based on the messages to the IETF list so far, it appears so.

For the record, I support a PR action against Dean due to his consistent
provocation of flame wars, particularly as they form a long-term 
pattern of

harassment of a particular company or persons.  Note that I consider it
irrelevant whether his position in this or any past instance turns out 
to be
correct: it's the form, not the content, of his efforts that is the 
problem.


S

[1] Many modern routers, particularly ones used in the Internet core, 
do not
even have the ability to enable PPLB, and the places where I've seen it 
used

in the last five years have exclusively been topologies that will always
re-merge the balanced traffic further upstream.
[2] I have seen misguided operators set MTUs below 200 bytes, but my
position is that these people deserve what they get in such cases.  We
cannot cater to deliberately broken implementations.

Stephen SprunkStupid people surround themselves with smart
CCIE #3723   people.  Smart people surround themselves with
K5SSS smart people who disagree with them.  --Aaron Sorkin


___
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: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Nick Staff]

C.M. - One of us has horribly missed the point of John's email (I'm not
inferring it's you).  Whichever one of us it is, the good news is I think we
actually agree with each other  =)

The passage you quoted was indeed quoted by John but the way I read his post
was that he was quoting it to show how this situation did not actually
apply.  That's why I asked him to provide relevant text from another rfc
other than 3683 since if he was saying that wasn't relevant I wanted to know
what was.

I support my interpretation by quoting what John said immediately after the
description:

This looks similar, but it does not require the one-year minimum, nor does
it require a LastCall.

Basically CM I agree with you wholeheartedly that the passage does apply and
that this situation should be governed by 3683.

nick
 
 On Tue, 27 Sep 2005, Nick Staff wrote:
  John-
  
  Could you please specify the RFC that details the procedure 
 for when 
  an AD requests that the IESG remove someone's posting 
 privileges from 
  the IETF list (the RFC other 3683 of course).  If there 
 isn't one then 
  I'd have to ask that you refrain from making wildly 
 unsupported claims 
  as they are disruptive to the process.
  
  Thanks,
  Nick
 
 Apparently you missed this in John's message (which you 
 quoted in its entirety, with garbled formatting):
 
  RFC2418 allows a WG chair and the ADs to also take measures 
 if someone 
  is disrupting WG progress (sect 3.2).
 ]
 ] As with face-to-face sessions occasionally one or more 
 individuals ] may engage in behavior on a mailing list which 
 disrupts the WG's ] progress.  In these cases the Chair 
 should attempt to discourage the ] behavior by communication 
 directly with the offending individual ] rather than on the 
 open mailing list.  If the behavior persists then ] the Chair 
 must involve the Area Director in the issue.  As a last ] 
 resort and after explicit warnings, the Area Director, with 
 the ] approval of the IESG, may request that the mailing list 
 maintainer ] block the ability of the offending individual to 
 post to the mailing ] list.
 
 Look on the second paragraph on Page 13.
 
 //cmh
 
 
 ___
 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: delegating (portions of) ietf list disciplinary process

[Nick Staff]

 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
 
 I'm interested to know whether people would see arguments for 
 either or both of
 
 1. An IETF Ombudsman (or Ombudscommittee), to act as a 
 dispute mediator.
 
 2. An IETF netiquette committee, to offload list banning 
 procedures from the IESG.
 
  Brian
Ahh, you beat me to the punch  ;)

I'm a big fan of the netiquette committee.  I'd like to suggest that
volunteers be allowed to throw their names into the hat and that members
be selected blindly from that pool.  This would of course avoid any stacking
or favoritism, but we would need a qualifier that prevented interlopers
from submitting their name.  Though I hate to suggest it as it would exclude
me from selection, having attended an IETF meeting in the last x years could
possibly be a good filter.

I'm probably getting ahead of things but I was also thinking some controls
could be implemented to discourage frivolous accusations.  I realize that
someone who repeatedly accuses falsely won't be taken seriously, but
sometimes the goal is disruption and uncertainty which unfortunately these
accusations are almost guaranteed to provide.

Anyway I think it's a great idea Brian.

nick


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

Re: IPR Trust - draft-carpenter-bcp101-update-02 and the IASA

[Jeffrey Hutzelman]

On Tuesday, September 27, 2005 08:08:02 PM -0400 John C Klensin 
[EMAIL PROTECTED] wrote:



Again, that justifies keeping the agreement private while you are
negotiating.  I don't question that.  As I understand BCP 101, you are
even entitled to keep such agreements private from the IESG and IAB while
you are negotiating them, informing those bodies and the community only
on a need to know basis.  The question I was asking was whether the IAOC
and/or the IESG expected the IETF community to approve a change in the
BCP without seeing the final trust agreement.  If that answer is no,
then I think we have a problem since this is a new entity that is not
intrinsically bound to the same requirements for public and open behavior
that apply to ISOC and the various IASA elements.


I think you mean If that answer is 'yes', 

I would hope that whatever trust agreement is reached provides for the same 
level of openness that we require of the IAOC.  Obviously we won't know 
until we see the final trust agreement.  I don't see how the IETF can 
possibly be expected to approve the proposed changes to BCP 101 without 
seeing that document.  I also believe it would be inappropriate for the 
trust to be formed and handed all of the IETF's IPR until those changes 
have been approved.


So, it seems to me like the process has to go something like this:

1) IAOC and CNRI reach a mutually-acceptable Trust Agreement
2) IAOC makes that document available to the IETF
3) IETF Last Call on the BCP 101 changes
4) Publish new BCP 101
5) Form the trust, using the agreement published in (2)





I'm maintaining the web site as a volunteer. The documents
that we can fully expose are available. We have a number of
documents/contacts/etc that can't be fully exposed (job
applications, for example) due to sensative content or
on-going negotiations.


I apologize if this sounds like micromanagement, but, if the IASA, which
was put together in large measure to move administrative tasks from IETF
volunteers to professional staff, requires you to maintain the web site
as a volunteer, then something is broken.  That web site and its
maintenance is part of the administrative function and is required under
the IASA BCP to keep the IETF community informed.   The IASA staff needs
to maintain it or make arrangements to keep it current and comprehensive,
with no excuses.


Cut them some slack, John.  Last I checked, the IASA didn't have a 
professional staff; it had one person.  The document I remember didn't 
require the ISOC to provide staff to maintain the IASA's web site, take 
minutes, etc, and it didn't empower the IAD to hire such staff, either. 
They're supposed to contract that stuff out to competent entities, and that 
process is still just starting.  In the meantime, assuming that all of the 
documents that can be made available are, as Lucy says they are, then I 
don't think lack of a professional webmaster is preventing the IASA from 
meeting its reporting obligations.




The minutes and the monthly reports are the best tool we have
for giving some insight into our process. They are developed
from notes taken by our volunteer scribe and are posted as
they are approved.


I probably have the same comment about volunteer scribe that I do about
volunteer web page.  That is how we used to do things, but it is part
of the problem the IASA was formed to solve.


See above, but more so.  I understand the IESG benefits enormously from 
having agendas, minutes, and the like handled by a professional who I'm 
told is very good at what she does.  Maybe the IAOC would benefit in the 
same way, and maybe not, but I think that's something we can safely let 
them figure out for themselves.


-- Jeff

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

Re: delegating (portions of) ietf list disciplinary process

[Theodore Ts'o]

On Tue, Sep 27, 2005 at 06:47:36PM -0700, Nick Staff wrote:
  2. An IETF netiquette committee, to offload list banning 
  procedures from the IESG.

 I'm a big fan of the netiquette committee.  I'd like to suggest that
 volunteers be allowed to throw their names into the hat and that members
 be selected blindly from that pool.  This would of course avoid any stacking
 or favoritism, but we would need a qualifier that prevented interlopers
 from submitting their name.  Though I hate to suggest it as it would exclude
 me from selection, having attended an IETF meeting in the last x years could
 possibly be a good filter.

Maybe.  I see two potential problems:

1) Serving on this committee is going to be no fun at all.  Getting
qualified people to sign up for what will only be seen as a sh*t job
is going to be difficult.  And how do you exclude certain known
(repeat) troublemakers from throwing their hat into the ring?  Or
maybe you don't, but then if they get selected, they would then have
the opportunity to practice their own unique form of DOS on the
netiquette committee?

2) Unless discussion of the decisions of the netiquette committee,
during the committee is considering a request, and after the committee
has rendered a decision, is ruled out of scope, it's not going to help
the very long discussions such as this one which plague the IETF list.
In the worst case, we can assume that the mailing list abuser will
immediately appeal any decision of the netiquette committee, which
means that after inventing this entire mechanism, it may not have any
effect other than prolonging the agony.

Problem (2) could be solved by making the decisions of the netiquette
committee not subject to appeal, but that causes its own problems and
potential for abuse of the people who do end up on the committee.  But
if you don't, then people who are intent on practicing their DOS
attacks (or otherwise impose their view of their world on us) will
simply use our procedures against us.

I suppose we could try to add some sanctions such as using a very
large ban time (measured in multiple years), so the benefit of trying
to get someone banned from the list is worth the cost, assuming we are
willing to preserve through the entire tortious process of (a) a
decision by the netiquette committe, (b) an appeal to the IESG, (c) an
appeal to the IAB, and eventually (d) an appeal to the Internet
Society --- or perhaps we could impose an automatic doubling of the
sanctions if someone attempts an appeal, and double the eventual ban
time at each level of appeal if the banning is eventually upheld.

But there isn't really a good solution to this problem, unfortunately.

- Ted

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

Monthly Report for the IAOC for August, 2005

[Brian Carpenter]

(Sent on behalf of Lucy Lynch, IAOC Chair)

Monthly Report for the IAOC for August, 2005.

The IETF Administrative Oversight Committee (IAOC) was formed 

to provide appropriate direction to the IAD [IETF Administrative Director],
 
to review the IAD's regular reports, and to oversee IASA functions to ensure
 
that the administrative needs of the IETF community are being properly met.

The IAOC is charged by BCP 101 with providing regular reports to the IETF
community; this monthly report is intended to serve as part of this reporting
requirement.

The current membership is (in alphabetical order):

   Brian Carpenter, IETF Chair, ex officio.
   Steve Crocker, appointed by the ISOC Board of Trustees for two years.
   Leslie Daigle, IAB Chair, ex officio.
   Ed Juskevicius, 1 Year NomCom Selection.
   Kurtis Lindqvist, appointed by the IESG for one year.
   Lucy Lynch, appointed by the IAB for two years.
   Lynn St Amour, ISOC President/CEO, ex officio.
   Jonne Soininen, 2 Year NomCom Selection.

In addition, Marshall Eubanks serves as the Secretary and scribe.

The IAOC conducts regular (presently weekly) teleconferences, for which minutes
are currently available at http://koi.uoregon.edu/~iaoc/. 

The work conducted by the IAOC during the month of August centered on the
following areas : IETF meetings, establishment of a Trust for IETF Intellectual
Property Rights (IPR), establishment of a contract for Secretariat Services, and
various housekeeping details.

IETF-63 in Paris, France :

The IAOC had Office Hours during the Paris IETF from 3:45 to 4:45 (local time),
Tuesday-Wednesday-Thursday, and presented during the Wednesday plenary. The
slides from the presentation are available at

http://koi.uoregon.edu/~iaoc/docs/ietf-63-iaoc.pdf .

Preparations for upcoming IETF Meetings :

Registration for IETF-64 was opened on August 31st. The IAOC and Neustar intend
to use this meeting as a template to better understand financial flows and
expenses associated with an IETF meeting.

Possible locations for meetings after IETF-64 were discussed at length in
August, and the IAD, along with IETF volunteers and personnel from Foretec and
NeuStar, made a site visit to evaluate possible locations for IETF-65 during the
week of August 22nd.

The IAD and the IETF Chair worked together to develop a survey questionnaire
aimed at IETF 63 meeting attendees to evaluate the meeting itself and suggest
changes to future meetings.  The survey was released publicly on August 17th,
and responses closed on August 26th; a total of  373 responses were received.
Survey results are available at  

http://geneva.isoc.org/surveys/results/IETF63/ .

IETF Trust :

The IAOC met with Robert Kahn of CNRI and Patrice Lyons, CNRI Counsel, on
August 3rd to discuss the the proposed IETF Trust for IPR. Based on comments
from this and other meetings, and their internal review, the IOAC prepared a new
draft Trust agreement during August. After discussion, the IAOC concluded that
this draft would benefit from additional legal review and asked the IETF Counsel
to forward it and the associated License documents for review by other counsel
at Wilmer Cutler Pickering Hale and Dorr. 

In addition, during the August 3rd meeting it was agreed that some of the text
in BCP 101 is based on assumptions that the IASA has moved beyond. The final
version of BCP 101, i.e., RFC 4071, assumed that the vehicle for certain
IETF-related Intellectual Property Rights (IPR) would be the Internet Society
(ISOC). Since the publication of RFC 4071, the IAOC has been working define and
create the IETF Trust to hold such IPR.  Since this Trust is not described in
BCP 101, the IAOC decided that a new BCP, to include the IETF Trust in the
definition of the IASA structure, would be of value, and Brian Carpenter
prepared a draft, draft-carpenter-bcp101-update-00.txt, with the IAOC's
assistance, to address this. This draft was submitted on August 17th.

Contract for Secretariat Services :

At present, there is no outstanding contract for the services provided by the
IETF Secretariat. The IAOC is empowered by the BCP 101 to execute such a
contract and is pursuing this matter vigorously. The IETF Secretariat is hosted
by Foretec Seminars Inc., a subsidiary of the Corporation for National Research
Initiatives (CNRI). Foretec is currently in the process of being sold to
NeuStar, Inc. Assuming that this sale is completed, the IAOC intends to contract
with NeuStar, if mutually acceptable terms can be reached, to provide these
services for a term not to exceed 2 years, with subsequent terms being
contracted under a formal Request for Proposals. 

On August 1st, in Paris, the IAOC met with Mark Foster, Jeff Neuman and Alan
Khalili from Neustar to discuss issues related to the shift of Secretariat
services, include the draft Statement of Work, IPR License, and the IEFT Trust.
The IAOC agreed that the IAD and the IETF Counsel, Jorge Contreras, should
prepare a draft IPR License 

Protocol Action: 'HDLC Frames over L2TPv3' to Proposed Standard

[The IESG]

The IESG has approved the following document:

- 'HDLC Frames over L2TPv3 '
   draft-ietf-l2tpext-pwe3-hdlc-07.txt as a Proposed Standard

This document is the product of the Layer Two Tunneling Protocol Extensions 
Working Group. 

The IESG contact persons are Margaret Wasserman and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-pwe3-hdlc-07.txt

Technical Summary
 
L2TPv3 is an evolution to the Layer 2 Tunneling Protocol defined in
RFC2661.  L2TP was originally designed to carry more than one link-type
if needed; however, since its origin resided in the pppext WG, the focus
of L2TP was PPP only.  After the formation of the L2TPEXT WG, multiple
proposals were submitted to carry various link-types over L2TP (circa
2000).  L2TPv3 was created as a way to consolidate these ideas into a
common protocol.  The WG decided to organize the documents
hierarchically, with one base L2TPv3 specification comprised of the vast
majority of the protocol and encapsulation definition to be followed by
specific documents for describing each specific link-type.

This document describes the specifics of how to tunnel
High-Level Data Link Control (HDLC) frames over L2TPv3.
 
Working Group Summary

The most challenging task this WG faced with respect to L2TPv3 was
extracting the base document from RFC2661. The follow-on documents
were relatively simple after that task was completed.

There has been cross-wg contention with respect to L2TPv3, largely in
that it is sometimes postulated as an IP-based alternative to some of
the VPN functionality being put into MPLS (e.g., with L2TPv3 you can
setup pseudo wires without an MPLS-enabled core network).

Protocol Quality
 
Protocol quality has been assured through detail WG and individual
review by Ignacio Goyret and Ron da Silva. 

This document was reviewed for the IESG by Margaret Wasserman.


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce