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
trust
[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 target
is
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
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 really
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).
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
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
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
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
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
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
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 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 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 the
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 the
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)
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
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 the two
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
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
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
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.
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 how, I
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
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
Some more
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
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
(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.
We
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
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 don't
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
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 documented is, on
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 them,
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
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
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
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
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 in
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
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 reaction is to use
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
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 'now'
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
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
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 are
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.
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
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
by an
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
- 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. the
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
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 reason
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
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.
from this
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 develop
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
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
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.
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
destination
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 wiki, it
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 of
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
What's the long-term plan for the RPKI implementation report -
publication?
yes. it is traditional in the routing area.
randy
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
aol
my apologies. i did not mean that formal implementation reports
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: There
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
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
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'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
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 someone
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
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
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.,
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
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
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 implementations
of
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
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
1 - 100 of 426 matches
Mail list logo
