pete,
since you did such an excellent draft capturing our local customs on
rough consensus, could we convince you to now do one on second guessing,
micro-management, and creation of petty bureaucracy, which seem to be
even more prevalent than rough consensus? thanks.
randy
> What I am saying is that if we that we want our leaders to only
> moderate discussion we are in a big problem.
we are in a big problem, and this is one major part. two decades of
lack of coherent architectural oversight is another symptom of this.
i'm surprised that we are not overwhelmed with
i have found it quite useful in venues other than the ietf. go for it.
and thanks, pete.
randy
>>To relieve routers of the load of performing certificate validation,
>>cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
>>does not provide object-based security to the router. I.e. the
>>router may not validate the data cryptographically from a well-known
>>
how about
To relieve routers of the load of performing certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the router. I.e. the
router may not validate the data cryptographically from a well-known
tr
>> [WEG] that's part of my issue - the only way that you get "close
>> enough that bootstrapping isn't a problem" is when the cache and
>> router are directly
> there's some baseline that's acceptable, you intimate that IGP comes
> up before EGP below. that makes some sense, and thus maybe the targ
> Following this line of reasoning (which is not unreasonable); if the
> router requires the cache to arrive at correctness, maybe the cache
> should be _inside_ the router.
yep. but no chance of it fitting in existing routers, and routers today
don't have the crypto oomph to validate (frequently
hi wes,
> why does proximity matter? Is this just an extension of the trust
> domain and limited dependence on routing protocols? If so, I'd
> dispense with recommending "close" because it confuses the issue and
> just keep the discussion about secondary dependencies and trust
> domains.
are you
take two paragraphs and call back in the morning if you are still in
pain :)
randy
In order that routers need not perform certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the router. I.e. the
route
> However, the concerns I raised during WGLC in
> http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html
> regarding the ambiguity of some of the guidance regarding location of
> RPKI caches ("close") in section 3 still have not been addressed. IMO
> if it is important enough to discuss pr
can we try to keep life simple? it is prudent to check what (new)
ipr exists for a draft at the point where the iesg is gonna start
the sausage machine to get it to rfc. if the iesg did not do this,
we would rightly worry that we were open to a submarine job. this
has happened, which is why this
> This assumes, of course, that current crypto technology
> (ciphers, anyway) is sufficient, which Schneier seems to
> think is the case.
side discussion wonders whether bruce may be a bit on the
pollyanna side on this aspect.
randy
so, it might be a good idea to hold a pgp signing party in van. but
there are interesting issues in doing so. we have done lots of parties
so have the social protocols and n00b cheat sheets. but that is the
trivial tip of the iceberg.
o is pgp compromised? just because it is not listed in [0
> OK, somebody has to say it. Maybe we should have another state,
> something like draft standard.
[ sob alluded to a private message from me which said ]
while i really like the idea of pushing well-tested interoperable
documents to full standards, i think tested interop is key here.
hence i li
so, according to your message, one lesson i might take from this is, if
i want to deploy a new hack which needs an rrtype, not to use txt in the
interim. i will be caught in a mess which will appear to be of my own
making. is that somewhat correct?
randy
> YANG seems to be incompatible with CBOR.
so what does that say about yang, yang's suitability for netconf, cbor,
and cbor's suitability?
randy
> Ironically, this IETF everyone who stayed at the Intercontinental was
> walking around with an RFID key in their pocket the whole meeting.
> How many of us put them in faraday cages?
one. i made it a habit
> I thought the experiment in Hiroshima went well
count me in the privacy concerns camp
> What did you think of Pete Resnick's draft about hums.
i like it a lot and have used it in other fora which are somewhat loose
or confused about consensus.
randy
> I would be very sorry to see IETF *working* meetings turned into
> something closer to conferences, or to dumbing things down to
> accommodate newcomers who I gather from discussion so far don't have
> anything particular in mind.
yup. i guess it is time for my quarterly suggestion to remove th
> I think it would be really helpful/useful if working groups could
> provide short video overviews to help people understand the work.
> This includes newcomers and also interested observers, who may include
> implementers.
putting up yuotube/vimeo tutorials on the wg's technical space would be
a
> I think IANA registration of namespaces has a lot of value.
let me ask the other side of the coin, in this case, what harm will be
done by not making this an rfc and registering the imei uri?
and i am not a fan of the mrs goldberg argument.
randy
> IMEIs are very pervasive, carried around by 100's of millions
> of people and generally not intended to be shared with the
> Internet.
my american social security card, which admittedly is a bit old, has
"Not to be used for identification" emblazoned on it in red.
for me, a seminal document was
global bgp never converges (and how would you know if it did?)
all devices fail, and two will fail at once
there is no more ipv4 free pool, get over it
there is not enough time on sunday for everything without conflict
there are never enough social tickets (but there is heavy last minute trading)
t
two hypotheses:
o there is no venue which is easy/acceptable to all ietf participants
o there is no ietf participant for whom all venues are easy/acceptable
randy, who is happy not to be on the meetings committee
> I notice most names in IETF are still presented in the English order,
> given name first and family name later.
same issue with japanese names. there seems to be a convention of
capitalizing the family name
randy
Spencer Dawkins wrote:
> - I'm not sure we can even know what the 10 voting members *were*
> guided by, unless the behavior is so bad that the advisor freaks out
> or the chair tells us in the plenary Nomcom report
and Yoav Nir wrote:
> how much can a nomcom member (or a pair of them) do to
> If I knew that 97% of appeals get rejected, I wouldn't even bother
> writing one...
i have never considered writng one. sour grapes make bad wine.
randy
> I guess you can prove attendance by Jabber log
as much of the acculturation happens outside of wgs, we can have the nsa
install jabber spies in the hallway. and they log everything!
randy
> Congratulations, gentlemen.
and they are all male
there appears to be a problem with your mail system. mail which is
clearly from the 1950s is appearing on the ietf list. somehow it has
current dates, so something is header mashing. you may need help with
your male system.
randy
>> You mean like "namedroppers"?
> If only we still had that list.
any reports of its death are from questionable sources
> it was the victim of politics.
like much of life
randy
> Given that this document was revved twice and had it's requested status
> change during IETF last call in response to discussion criticism and new
> contribution I am going to rerun the last call.
the recent changes resolved my issue. thanks joe and joel.
randy
> As for the rest of the discussion - I'm sure there are things to be
> improved in ICANN. I'd suggest though that some of the feedback might
> be better placed in an ICANN discussion than on IETF list.
when that feedback is that the icann does not really listen to feedback,
i think there is a pro
> I am told that draft has been revved again in response to discussion on
> the list.
>
> http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05
>
> Please direct your attention to the security considerations section. If
> it turns out that informational documentation of th
> Right. We've had some issues with document quality, and I
> can think of several documents that sailed through WG last
> call and should not have.
there was a doc with which i had a small, but non trivial, issue. the
author and the wg did not think it worthwhile. i did not want to argue
endle
> Re-formulating the LC text sounds like an excellent idea, to call for
> more substantive comments.
perhaps we should go to the source of the problem and require a phd
dissertation and defense from draft authors.
how much process chaos can we create?
randy
so now i am expected to do a write-up of why i show simple support of a
document i have read? may i use carbon paper for the triplicate, or
will a copier suffice? surely we can find a way to waste more time and
effort.
randy
> I'm not sure how the desire for IETF Last Call discussions to be on a
> dedicated and constrained mailing list
many years ago, a housing development thought they had a bad crime rate.
so they built a fence around it and only let residents in. the crime
rate stayed the same. funny thing.
procm
> I was working on TCP/IP, Novell and AppleTalk nets in the mid 90s and
> as network engineers we hated to maintain a database of static IP
> addresses for users, and we loved how AT for example was totally
> automatic (IPX was in the middle because we also hated the long addresses).
>
> But any h
> Heavens no. All meetings should be in Santa Barbara, so I don't have
> to board an airplane at all.
i too, but tokyo. induce. answer, remote participation. i hope that a
decade from now many of us will not need to fly.
randy
< rant >
the sad fact is that the ietf culture is often not very good at
listening to the (ops) customer. look at the cf we have made out of
ipv6. the end user, and the op, want the absolute minimal change and
cost, let me get an ipv6 allocation from the integer rental monopoly,
flip a switch or
> Yup. And some operators have decided that the IETF document
> development and consensus-forming process is sufficiently annoying
> that they are standing up their own forum for Best Common Practice
> docs:
> http://www.ipbcop.org/ -- "Documented best practices for Engineers by
> Engineers"
> Som
melinda,
i assure you that operations being 'owned' by vendors is not restricted
to the geographically isolated. one small example. i was asked to
consult on a global deployment by a global fortune whatever company
whose name you would all recognize. there was no real management, and
the decisi
>> Yes, I'm sure.
>> Your turn now.
>> Are you sure?
> No, not at all.
did you somehow miss the pdu data formats and exchange ladder diagram?
if this is not a process document, then what the heck is it, chopped
liver?
randy
> (2) As far as I can tell, the operators in most regions are
> generally well represented in, and collaborate using, the
> various *NOGs.
the first derivative is generally positive. a lot of fluff, machismo,
and posturing, but that seems to come with any endeavor involving us
funny monkeys.
> W
>> remove the rrtypes from the registry
> While it's good to see that the Internet Exemplary Taste-enForcers are
> alive and well, I would have an extremely strong objection to that
> approach.
jck was trying to enumerate alternatives. he omitted one. i am not a
particular advocate of any of the
>>> What is at issue, IMO, is whether the Internet is better off
>>> having a couple of RRTYPEs around with no documentation or
>>> having them documented.
>>
>> there are two solutions to this
>
> Probably more than two if your comment indicates that you agree
> that having registered RRTYPEs do
> What is at issue, IMO, is whether the Internet is better off
> having a couple of RRTYPEs around with no documentation or
> having them documented.
there are two solutions to this
randy
>> while i appreciate joe's listening to my other comments on the draft, i
>> still strongly object to publication of this draft as an rfc for the
>> reasons made very clear in the sec cons. please read the summary
>> section of rfc 2804.
>
> While the RFC should not be materially misleading, I d
while i appreciate joe's listening to my other comments on the draft, i
still strongly object to publication of this draft as an rfc for the
reasons made very clear in the sec cons. please read the summary
section of rfc 2804.
randy
joe,
i spent time actually reading the document and commenting on it, one was
a substantive comment, at least to me.
any chance you could pull yourself away from the exemplary
anti-productive nitpicking maelstrom for a few minutes and respond?
thanks.
randy
>> With respect to the question of proposed standard. What changes if the
>> requested status is informational?
>
> I think just get rid of the normative language - SHOULDs, MUSTs, etc.
that is orthogonal to info/ps
next unnecessary rathole, please
randy
> Without responding in detail to John's note, I'll say that I agree
> substantially with the notion that the fact that someone manages to get
> a protocol name or number registered, should not be any kind of
> justification for standardization of a document that describes use of
> that name or
joe,
i have read the draft. if published, i would prefer it as a proposed
standard as it does specify protocol data objects.
< where you goin' with that gun in your hand? >
i am not at all sanguine about the issues raised in the in sec cons. i
accept that NTRE038D may have asked that these be i
dear emperor, despite the braggadocio, there seems to be a shortage of
attire. icann is notorious for pretending to be open but being
effectively closed. it solicits public comment and ignores it. i could
go on and on, but i am far less wordy.
randy
> To be abundantly clear, you are hypothesizing a difference of opinion
> between the IETF/IESG and the ICANN/RIR communities, wherein the
> technical guidance of the IETF was considered during the ICANN/RIR
> decision process, but in the end the outcome was contrary to IETF
> expectations.
if you
> Without wishing to be nasty, I will point out that we have way more
> vendors than operators participating in our standards development.
Into the Future with the Internet Vendor Task Force
A very Curmudgeonly View
or
>>> MAY != SHOULD
>> The text is as follows: "The name SHOULD be fully qualified whenever
>> possible". If the working group would like a RFC 2119 SHOULD it
>> would help if there is an explanation in the sentence for the reader
>> weigh the implications of not following that.
> My knee-jerk react
>"The domain-name type represents a DNS domain name. The
> name SHOULD be fully qualified whenever possible."
>
> That sounds like a MAY.
MAY != SHOULD
> One possible step is to have WG Chairs be *managers*, like they are
> supposed to be.
> ...
> The current cycle too often seems to be more like "new version
> posted". Wait if anyone reviews. Some reviews eventually, maybe. Oh,
> IETF meeting coming, time for a revision.
with wg chairs taking
seems to me that
o spf is still used, whether we think it is a good idea or not
o spf is using the spf rrtype
o we don't shoot an rrtype which is still being used
o overloading txt with a whole lot of things we don't like is
stupid++ for s many reasons
if you don't like spf, then *
> Working groups were taking around 500 days and now take around 600.
>
> The IESG was taking around 200 days and now takes around 110.
>
> The RFC then and now takes around 100 days (with lots of variation
> between the then and the now, of course.)
>
> Considering the
you don't need a weatherman to know which way the wind blows.
-- bob dylan
we do not need measurements to know the ietf is embarrassingly
non-diverse. it is derived from and embedded in an embarrassingly
non-diverse culture.
we need to do what we can to remedy this. progress not perfection is
o
> There is technical work other than late-stage document reviews. We
> might get a larger return on investment if community members who are
> temporarily serving in the area director role were to spend more of
> their combined technical and management talent on making sure that our
> working groups
> IMO congestion control is important and fundamental enough that the
> IESG itself needs to have the knowledge. Yes, I'm biased.
as an operator and as an ex area director, i have the same bias.
transport is the waist of the hourglass. "importand and fundamental"
are a good choice of words.
as
>>> For me the most important point is that it is managed on IETF (or IETF's
>>> contractor) servers.
>> as no private data are involved, i am curious why?
> Because public does not mean unlimited availability. Let's say that
> the IETF decides to use a collaboration tool hosted by a service run
>
> For me the most important point is that it is managed on IETF (or
> IETF's contractor) servers.
as no private data are involved, i am curious why?
randy
>> - the Bert version uses DNS strings that aren't valid
>> (*, +, ',', ++)
this is not an accident
> Are we going to open again the question whether the DNS protocol can
> handle any value in the octets, as compared to the hostname definition
> that says something more limited? ;-)
no need.
my take is that we have advanced to that stage of organizational life
where we have newcomers who, when faced with a new culture with subtle
process, are led by personal and/or cultural background to assert that
the process should be changed to a model which they already understand,
and for it to b
> I am setting a deadline for slides for IETF86 for my WG, and I will be
> doing a unified slide deck. I might allow text on a slide to be
> updated the day before... but no slides, no speak.
i know this will come as a shock to many, but some of us occasionally
choose to speak *without powerpoint
> We often pick on every suggested change and point out every possible
> flaw, with different people holding out behind different flaws, and we
> get stuck there. There seems to be some assumption, when we do this,
> that our current process doesn't also have significant flaws. But the
> very rea
> fighting fiefdoms is a waste of time. the answer is to shut them the
> hell down.
a friend asked (to put it politely:-) me to clarify.
[ first, mea multi culpea, i helped start and/or served on the board (or
equivalent) of a number of the organizations against which i rail.
consider me the
< more vituperation >
>> we need bookkeepers. we get wannabe regulators.
> +1
and, as a friend pointed out, in sidr, we are arming them. i try hard
to ameliorate this. but that's another subject.
> I don't believe moving RFC 2050 to historic implies the operational
> community efforts to de
< vituperation >
> I believe RFC 2050 does (and did) _not_ address "technical
> specifications of addresses", but rather documented (past tense) the
> then "best current practice" of policies associated with the
> operational deployment of those addresses for a short period around
> 1995 or so.
f
> If Jon were participating in this conversation today, I'm quite sure
> that he would be saying that it is much more important for the RIRs
> and the IETF to work together to get the best result for the Internet
> rather than putting energy into trying to legislate or enforce a
> boundary (whether
>> And that consent is based on information availability. Manage the
>> information, and you manage the consent.
> Possibly; the extent to which that management is obvious may, of course,
> drive other behavior (cf. самизда́т [Samizdat] and similar efforts).
or, in the states, wikileaks.
http:/
ron,
> I have just posted draft-bonica-special-purpose-05. I hope that this
> version addressed the issues that we discussed, off-line.
indeed it does. s/prefix/address block/ and s/routable/forwardable/
hits my two issues on the head. thank you.
it might be good if, now that these changes h
> In most countries, wiretap laws apply to public facilities.
laws do not seem to have much relation to government spying.
randy
> born in 1963, i felt throughout the 70's and 80's that i had been born
> too late, that all the fun stuff had been done already. now in the
> 10's i feel like we're just getting going and that i was probably born
> too soon, that all the fun stuff is coming 50 years from now.
if you missed the '
i remain confused. i am not being pedantic just to be a pita. i really
worry that this document will be used to justtify strange brokenness.
from my 2012.11.29 message:
> are the following definitions
>
>o Routable - A boolean value indicating whether a IP datagram whose
> destinati
> I am surprised at this. Gathering information about implementations is
> something that happens in some WGs and not in others, but it is always
> the chair that is driving it, often as part of the write-up prior to
> IETF Last Call.
uh, not really. in some wg cultures, it's just seen as part o
> to clarify, my proposal only applies to Internet Drafts, and clearly
> states that the implementation section should be removed from the
> document before it is published as RFC.
>
> Formally, we don't want non-permanent stuff in RFCs. And realistically,
> even if we had an implementation wik
> My concern remains that we not create new formal procedures to do (or
> even experiment with) things that can be done under existing rules
> either for the whole IETF or on an area by area or even document by
> document basis
my apologies. i did not mean that formal implementation reports sho
> What's the long-term plan for the RPKI implementation report -
> publication?
yes. it is traditional in the routing area.
randy
don't we already have a way of doing this? implementation reports, e.g.
draft-ietf-sidr-rpki-rtr-impl-01.txt
a wiki can be more easily curated, though has authorization challenges.
could you clue me into how the different modes would facilitate progress
of the base document(s)?
randy
> I'm increasingly not a fan of process documents.
the rise of a bureaucratic class is a dangerous sign of ossification.
i just failed gobbling for an image of the net police ticket dr postel
used to have on his wall. if anyone has an image, i would dearly love
a copy. advthanksance.
randy
>> Given that there is also open source code, reviewers have the chance
>> to take a look at that and see the degree of hackiness involved.
>
> Well, yes. It's easy enough to evaluate stuff such as non-descriptive
> variable names, messy indenting, and weird comments.
>
> But there's a catch here
>>> I'm unclear on how we'd carry on a discussion without a floor
>>> management discipline.
>> i know it's a leap, but maybe presume people are adults
> and that everyone of them has a microphone
so we build our meetings around the fears, will someone speak
unacceptably, will someone appeal, will
> I'm unclear on how we'd carry on a discussion without a floor management
> discipline.
i know it's a leap, but maybe presume people are adults
> What I meant is that accepting the I+D as WG document clears the path
> of the bad idea to become RFC somehow or at least to waste a lot of
> time fighting against it.
we used to call that 'discussion' as opposed to ppt presentation. and
discussion is what wgs were for, see other thread.
randy
> I would prefer to have the I+D as non-wg item until we are sure that we
> are willing to support it as RFC.
i thought that was wglc. but i am a dinosaur.
randy
> So it is ok to have bad ideas as I+D, possibly harmful for the Internet
> just to have a structured discussion?
and so that the chairs have the option of changing editorship to turn
them into good ideas.
randy
sadly, too many of us remember writing on scrolls of acetate. i
imagine that some remember stone and chisels.
ok, just for a gedanken experiment of one extreme,
o remove the projector. [ omg! how will we show the note hell? ]
o if there is an active draft that *really* needs f2f discussio
> Yes, it is possible to add an attribute to a common registry.
>
> On the other hand it is possible to realign what entries go in which
> registry according to:
>
> - "reservations" to be in the "main" registry, using a working
> definition of a "reservation" as something that all implementati
hi geoff,
i get your point. but it sure is convenient to find everything in one
place. can your issues be addressed by adding an attribute(s) to the
entries?
randy
> As a document author, I've learned that I need to have a friend take
> good notes for me, because all of the great comments I get at the mike
> are lost otherwise.
this gap makes me crazy, so much is often lost. but i do not think
technology or process will close this hole. too much depends on
first cuppa, so i am easily confuddled. and apologies for doing this at
last call.
are the following definitions
o Routable - A boolean value indicating whether a IP datagram whose
destination address is drawn from the allocated special-purpose
address block is routable (i.e., ma
> I'll note that it seems possible that overspecifying process
> could potentially cause more protests rather than fewer.
or good folk just walking away. there is a reason we are at the ietf
and not the itu. rule obsessed and process hidebound is probably not
the most productive use of smart fol
> It is a fact of life that some WGs only make progress face-to-face. I
> think that's often a sign of a problem, but it's a fact.
i am not so sure it's a problem. email is a great miscommunication
mechanism. so mailing lists go disfunctional far more easily than face
to face.
we're funny monke
> I'm increasingly seeing a "paradigm" where the review happens _before_
> adoption as a WG draft.
and one consequence is that the design gets done outside of the ietf
process.
randy
1 - 100 of 476 matches
Mail list logo
