Le 2013-03-12 à 14:45, John C Klensin a écrit :
> Hi
>
> At last night's plenary, I raised some related issues about the
> difficulties posed by the interactions between current systems
> for developing and editing documents working groups through the
> approval and publication processes and th
Le 2013-03-12 à 11:19, Mary Barnes a écrit :
> On Tue, Mar 12, 2013 at 10:00 AM, Michael StJohns
> wrote:
>> At 07:56 AM 3/12/2013, Dan Harkins wrote:
>>> While these studies are interesting and thought provoking, I think it is
>>> wrong, and very dangerous, to use these studies to justify bla
Le 2013-03-11 à 13:43, Arturo Servin a écrit :
> Hi,
>
> I have been reading the comments in the list and although I am not
> making a specific reply to any message I would like to make some comments.
>
> So far I have read "I agree we need some diversity" or "I agree that
> more d
Le 2013-03-11 à 12:41, "Fred Baker (fred)" a écrit :
>
> On Mar 10, 2013, at 1:57 PM, Spencer Dawkins
> wrote:
>
>> On 3/10/2013 5:22 AM, IETF Diversity wrote:
>>
>> I'm listed as a signatory and agree that this is important.
>>
>>> There are several steps that could be taken, in the short
Le 2013-02-07 à 09:46, Thomas Narten a écrit :
> It is good to document what we have been doing. But the text seems to
> focus on technology and tools…
I agree and disagree.
>
> IMO, what is missing is operational Best Practices. We seem to be
> lacking them (are any written down?) And we don'
starting
>> point. Duplicate documentation in wiki may be useful and provide a place to
>> track text for inclusion in the next revision.
>>
>> When/if inclusion in the I-D gets messy, replace text in I-D with pointer to
>> wiki.
>>
>> When/if experimen
> When/if inclusion in the I-D gets messy, replace text in I-D with pointer to
> wiki.
>
> When/if experiment looks like a success, replace all above with data tracker
> tool and allow it to persist for RFCs.
makes sense to me.
Marc.
>
> Adrian
>
>&
t online within our site
- but you wrote: requires implementation effort.
- I replied: well, phase 1 (of put it online within our site) can be done with
almost zero implementation effort. phase 2 requires some work (I'd say not that
big) for implementation/tools.
Regards, Marc.
> Thanks,
>
Le 2012-12-13 à 09:52, Yaron Sheffer a écrit :
> Hi Adrian,
>
> I would suggest to start with my proposal, because it requires zero
> implementation effort.
disagree. phase 1: use IETF wiki. phase 2: develop an widget within data
tracker.
Marc.
> If this catches on, I see a lot of value in
Le 2012-12-13 à 09:16, Adrian Farrel a écrit :
> I'm interested in this idea.
>
> However, I note that an "implementation status" section of a document is
> frozen
> in time when a document goes to RFC.
>
> I wonder whether we could leverage our tools and do something similar to IPR
> disclosu
Le 2012-12-05 à 04:25, Tschofenig, Hannes (NSN - FI/Espoo) a écrit :
> Hi Donald,
>
>> It's a question of costs and benefits. The cost of the IETF Announce
>> posting is small. There are not that many of them and I don't find
>> them to be a burden.
>
> How many conference calls as part of wor
Le 2012-11-27 à 13:00, Barry Leiba a écrit :
>
> So here's my question:
> Does the community want us to push back on those situations? Does the
> community believe that the real IETF work is done on the mailing
> lists, and not in the face-to-face meetings, to the extent that the
> community wou
cool!!! I will also be using this! thanks!
Marc.
Le 2012-07-31 à 11:16, Ole Jacobsen a écrit :
>
> In The Internet Protocol Journal I have been using the following
> citation format, best illustrated by an example:
>
> Julien Meuric, Diego Caviglia, Don Fedyk, Attila Takacs, and Lou
> Berge
If I look around me, I see young people developing PHP, AJAX, … almost all of
this is not handled in IETF. If I look at company valuations recently, there
are at the same "level" in the stack: i.e. web apps. So I guess the plumbers
are getting old, but the designers are younger and not here.
M
I agree with everything Scott wrote. I don't see a good reason for removing
code points from a registry, unless very exceptional cases (range is almost
full need more space), which could be processed as one-off, not as a regular
process.
Marc.
Le 2012-04-19 à 16:48, Scott O Bradner a écrit :
I wonder if this document should be instead Informational status. I
don't see here a protocol, more an implementation optimisation.
Marc.
Le 11-01-13 18:58, The IESG a écrit :
The IESG has received a request from an individual submitter to consider
the following document:
- 'Scalable Operatio
Le 10-05-19 09:40, Peter Saint-Andre a écrit :
On 5/18/10 12:32 PM, Marc Blanchet wrote:
Le 10-05-18 14:27, Sam Hartman a écrit :
"Marc" == Marc Blanchet writes:
Marc> we had a discussion about the same subject: i.e. should we
Marc> restrict the scope to a
Le 10-05-18 14:27, Sam Hartman a écrit :
"Marc" == Marc Blanchet writes:
Marc> we had a discussion about the same subject: i.e. should we
Marc> restrict the scope to a specific set of documents to
Marc> review/update/... or do we keep some provision
we had a discussion about the same subject: i.e. should we restrict the
scope to a specific set of documents to review/update/... or do we keep
some provision for other documents coming in the stream that require
"help" of the newprep. I was arguing for the latter. To me, what you are
talking a
Marshall Eubanks a écrit :
>
> On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote:
>
>> Marshall Eubanks a écrit :
>>>
>>> Emergencies. An emergency is defined as "there is a problem with the
>>> TLP that is likely to be abused". In these c
Marshall Eubanks a écrit :
>
> Emergencies. An emergency is defined as "there is a problem with the
> TLP that is likely to be abused". In these cases, the trust can publish
> a modified text for a 2 week review period, then modify the TLP. The
> Trust must explain the reason for the chan
Jari Arkko a écrit :
>
> This revision includes the removal of the BCP document. I am hoping that
> also helps in other problems people had with this charter, as it becomes
> even clearer that the WG will not develop solutions, its really only
> about describing the problem and existing practices.
Giyeong Son a écrit :
> I think we may need to understand what are the real problems that
> people/organizations (i.e. carriers, ISPs and vendors and users) have
> been currently struggling with in terms of simultaneous use of multiple
> networks.
there is a first cut in draft-blanchet-mif-proble
Christian's suggestion is one way. not sure it is complete.
but I don't agree with you (Deng): i.e. I think this suggestion is in
scope of MIF wg. Maybe the outcome of the wg is a best practice document
that tells application developers how to write "good" applications in
context of MIF, where one
Ralph Droms a écrit :
> Christian - I think address selection is part but not all of the problem.
>
> I would be happy to see a summary of current practice in dealing with
> simultaneous attachment to multiple networks. How does an iPhone decide
> between its WiFi and dell interfaces? How does a
Jari Arkko a écrit :
>
> But my main point is that the MIF charter covers -- on purpose -- a
> relatively large problem area. We need to describe the problem as
> experienced by real-life implementations without constraining ourselves
> too much at this stage. Once we finally understand the proble
Le 07-07-01 à 20:24, Jun-ichiro itojun Hagino a écrit :
you right. we have been running dual stack network since 1998 or
something (Marc Blanchet should have the real answer),
Chicago IETF 42nd. Aug 1998.
Marc.
-
IPv6 book: Migrating to IPv6, Wiley, 2006, http
gt; But forget legal issues for a moment, these are to be discussed
> elsewhere. I'd like to ask you for your personal opinion, not your
> legal knowledge or appraisal:
>
>
> Is that the way IETF treats it's contributors?
> Is that consid
ir languages, making it very difficult to figure out how
> native words would be spelled in it.
>
> Mark
>
--
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
--
http://www.freenet6.net: IPv6 connectivity
--
Feb, 03: Initial draft of working group specifications.
>
> Jun, 03: Specifications submitted for IETF approval
>
>
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> Sunnyvale, CA USA
>
--
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
--
http://www.freenet6.net: IPv6 connectivity
--
te-of-the-art"
presentations.
Marc.
>
> Keith
--
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
--
http://www.freenet6.net: IPv6 connectivity
--
ohama, same as in Minneapolis? Most flights to Europe are
>> around noon, in case meetings are scheduled on Friday people in Europe
>> will need to schedule their flight on Saturday.
>>
>> Thanks
>> Cedric
>
>
--
Mar
to let people explain their views at whatever length that
> takes?
>
> thanks,
>
> john
> (for the IAB)
--
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225
--
http://www.freenet6.net: IPv6 connectivity
--
http://www.normos.org: IETF(RFC,draft),
IANA,W3C,... standards.
--
tending the IETF (too many), the Minneapolis
> > Hilton has the best facilities, best sized rooms, most cookies and pops,
> > and the best run meetings of the bunch. Who cares what the temperature
> > outside is?
>
>--
>
>[EMAIL PROTECTED]
> Key fingerprint = 17 40 5E
bably still a good idea. Or New
>Orleans, at least it is warm and centrally located.
sorry, but this is a US centric comment. IETF is international, so
centrally located is an interesting question: center of the earth (probably
enough ho
web site: http://www.i-d-n.net.
Marc.
> Of course, the general IETF mailing list might not
> be the right venue for continued conversation.
>
>--bill
Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca
--
):
http://www.normos.org/ietf/draft.tgz
ftp://ftp.normos.org/ietf/draft.tgz
rfcs (36M, tar-gzipped):
http://www.normos.org/ietf/rfc.tgz
ftp://ftp.normos.org/ietf/rfc.tgz
Regards, Marc.
Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca
Agendas (37K, tar-gzipped):
http://www.normos.org/ietf/ietf-agendas.tgz
ftp://ftp.normos.org/ietf/ietf-agendas.tgz
Regards, Marc.
Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca
--
Normos (http://www.normos.org
At 10:49 2000-02-16 -0500, [EMAIL PROTECTED] wrote:
>Noticed this one this morning:
>
>--- start excerpt
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
> Title : Compatible Internationalized Domain Names Using
> Co
cements (of 175 /16 equivalents of space) in
> > 147.0.0.0 and the table at http://www.isi.edu/~bmanning/in-addr-data.html
> > shows 193 in-addr.arpa entries.
> >
> > so how can the data at www.isi.edu/~bmanning/in-addr-audit.html be
> > interpreted to give a useful re
interface in nederland
Marc.
---
Marc Blanchet | [EMAIL PROTECTED]
Viagénie inc. | http://www.viagenie.qc.ca
2875 boul. Laurier, suite 300 | tél.: 418-656-9254
Ste-Foy, Québec | fax.: 418-266-5539
41 matches
Mail list logo
