Brian, in my experience working group adoption is more than the working
group agreeing to work on the topic. It is generally the working group
agreeing that the given document is a good basis for starting the work.
Yes, there will almost always be need for improvement. Sometimes
major
for the IETF. You need to actually get a determination of IETF rough
consensus on the ietf email list. That consensus would need to be based
on a more specific question than do we want to allow ORCHIDs, and then
would be judged on that question by the IETF chair.
Yours,
Joel M. Halpern
On 9/17
Maybe I am missing something.
The reason we have face-to-face meetings is because there is value in
such meetings that can not reasonably be achieved in other ways.
I would like remote participation to be as good as possible. But if
would could achieve the same as being there then we should
Thank you, and ISOC. Well done.
Joel
On 7/5/2013 11:57 AM, The IAOC wrote:
Registration was suspended after discussions with tax specialists and attorneys
convinced
us that that the rules had changed in the EU and Germany with regard to the
impact of the
Value Added Tax (VAT) on registration
In reading through the draft, particularly the section on questions for
WG adoption of a draft, I did not see the questions I consider most
pertinent:
Does the WG think this is a reasonable (preferably good) basis for
starting to work collectively on the deliverable?
(Apologies if it was
A Mechanism for Transporting User to User
Call Control Information in SIP
Reviewer: Joel M. Halpern
Review Date: 19-May-2013
IETF LC End Date: 29-May-2013
IESG Telechat date: N/A
Summary: This document is nearly ready for publication as a Proposed
Standard
Major issues:
Minor issues
It seems to me that if it is really a discussion, then there may be many
possible things which could resolve it, and the AD raising the question
may not know exactly what is feasible to clear it. Otherwise it is a
demand, not a discussions. And in my experience while ADs can be pushy
(like
Below:
On 5/14/2013 6:04 PM, Joe Touch wrote:
On 5/14/2013 3:00 PM, Joel M. Halpern wrote:
It seems to me that if it is really a discussion, then there may be many
possible things which could resolve it, and the AD raising the question
may not know exactly what is feasible to clear
And your bottom line is exactly what te rules say, what I said, what Ted
said, and what Joe agreed is reasonable. It also matchesthe practice I
have seen. Even the discuss that I had a lot of arguments with did
include proposals for paths forward. Sometimes they were ard to
understand.
.
(The fact that I find the vague pattern for the child misleading
is not a fault with the document, but rather in my head, under
that requirement.)
Yours,
Joel
On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see
for X and the pattern for
Y? If so, then my concern below is misplaced. (The fact that I find
the vague pattern for the child misleading is not a fault with the
document, but rather in my head, under that requirement.)
Yours,
Joel
On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
I am
Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A
Summary: This document is nearly ready for publication as a Standards
Track RFC
Major issues:
(The following may well be a non-issue.)
In the revision of the ietf
I have a draft version with this correction.
David, would adding:
When such a move
is done without changing the MAC address, the SAVI switches
will need to update their state. While the ARP may be
helpful,
traffic detection, switch based neighbor
Would it suffice to replace
Old:
If the bridging topologies which connects the switches changes, or
if LACP [IEEE802.3ad] changes which links are used to deliver
traffic, the switch may need to move the SAVI state to a different
port, are the state may need to be moved or
It seems to me that you are setting up by assertion a standard that has
never applied to this community.
Having said that, if we want to go down this path, then we could do what
groups like IEEE do. Remove all authors names, all personal
acknowledgements, etc. The work is simply the product
I think I at least partly disagree. The acknowledgements section of
RFCs was not, and to the best of my knowledge is not, concerned with
capturing the history of where specific changes or ideas came from. It
ought to be concerned with giving credit to folks who made particularly
large, but
I would have to disagree with:
On 3/22/2013 11:17 PM, Mark Prior wrote:
...
Hi John,
I think that any small shop (whatever that means) would be put off if
they sent someone to an IETF as it appears that it is dominated by the
big vendors pushing their own agendas. Given that impression I
-14.txt
Flow Selection Techniques
Reviewer: Joel M. Halpern
Review Date: 21-March-2013
IETF LC End Date: 1-April-2013
IESG Telechat date: N/A
Summary: This document is ready for publication as a proposed standard.
Major issues: none (the previous major issue has been resolved by
revision
With apologies for the problems making these slides available, and
thanks to Bernard for finding a work-around, for now the slides are
available via links from
http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/
Yours,
Joel M. Halpern
Original Message
Subject
I read 3777 as somewhere in between, with some important caveats.
As I understand the rules and practice of the game we are playing:
The IESG (and the IAB and IAOC) specify what they want to see (their job
requirements).
The nomcom collects those, and community input. Community input is
Gaving discussed TCP Congestion behavior with the TCP folks, and tried
to understand the issues, it seems to be very hard.
And if the AD is not well-versed in it, there is a serious issue. It
seems to me that unless we restructure the entire way the IESG operates
(maybe a good idea, but a
Keith, you seem to be asking for something (discussion, wit no
presentation), that has never happened in the WGs I have attended in the
last 20 years. Even the WG sessions that had the best, most useful,
discussions, generally started with a presentation of the topic and issue.
Such initial
, can we live with these? I would think so.
Yours,
Joel
On 12/19/2012 6:14 PM, Nick Hilliard wrote:
On 18/12/2012 22:26, Joel M. Halpern wrote:
Nick, I appreciate that you have read this document and commented.
Two general questions:
1) Can you be more specific about where you see unclear
Nick, I appreciate that you have read this document and commented.
Two general questions:
1) Can you be more specific about where you see unclear language usage?
It is hard to fix a general coment.
2) A number of your comments seem to be about general router security.
Many of them would see
And I will strongly oppose any IETF policy that treats commercial or
proprietary code differently from Open Source code.
Out mantra is running code. We try to stay out of people's business
models.
The presence of a implementation is a useful measure. The presence of
interoperability
There is another unfortunate community habit that I have noticed.
It is, I believe, a consequence o their being simply too much stuff to
look at.
If you have a working group that is considering new ideas (looking to
recharter), you are more likely to get folks to read the draft, either
It is a fair question to ask whether the allocation strategy and polices
need to be spelled out at the time of the reservation. Possibly we made
the wrong call on keeping them separate. Part of the issue is that fo
current experimentation having the block is more important, but for
longer
sizes for everyone.
Yours,
Joel
On 11/16/2012 11:35 AM, Brian E Carpenter wrote:
Joel,
On 16/11/2012 16:00, Joel M. Halpern wrote:
...
With regard to interworking and deployment, there are a number of
documents that deal with that. They discuss what the currently
understood deployment
Whatever else is going on, LISP EIDs do not have geographic
significance. They do not have IP Routing topological significance.
The are not aggregateable.
They are intended to beused by a site as a single prefix. Hence, the
desired behavior (within the /16) is exactly the same as that
management quesiton is made significantly
easier by having a clean architecture description.
Yours,
Joel
On 3/14/2012 10:40 AM, John Scudder wrote:
One further remark:
On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:
...
It may take engineering and evaluating some cache management schemes
Actually John, I would have to disagree with your assertion about what
it takes to describe the archtiecture.
It may take engineering and evaluating some cache management schemes
before one can decide whether the archtiecture is a good one. But that
is very different from being able to
If I may separate issues for a moment,
the absence of milestones is because Terry and I have to come up with a
proposal for them which matche sthe revised goals.
If you read the rest of the differences, you will see that the general
question of what LISP is aimed at providing is indeed still
I agree. This needs to be published by the IETF as an RFC. the current
form is quite suitable for that.
Yours,
Joel
On 2/14/2012 1:28 PM, Scott O Bradner wrote:
+1
On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:
+1.
Ross
*From:*ietf-boun...@ietf.org
I suspect that the correct choices depends upon how you look at the
analogy.
What seemed to me the closest analog to process would be the actual
messages on the wires.
yours,
Joel
On 1/5/2012 10:03 PM, Dave CROCKER wrote:
On 1/5/2012 1:41 PM, Dave Cridland wrote:
Association, to my mind,
a) It would seem sensible to leave the selection of the specific lawyer
to the IASA / IAOC.
b) I would hope that they will select a lawyer with specific exposure to
anti-trust issues. That may well turn out to be the existing IETF counsel.
Yours,
Joel
On 11/28/2011 1:57 PM, Marshall Eubanks
Regarding the delegating the IETF chair participation in the IAOC,
On 9/22/2011 8:55 AM, Bob Hinden wrote:
IETF Chair
The IETF chair is chosen by the nomcom. The job requirements are clear in
advance. Anyone applying is aware of the job. I don't think the IETF Chair
position on the IAOC
There seem to be at least two different dimensions here, probably more.
On the one hand, when I discuss with someone (in an airport, hotel,
whatever) an idea for a protocol behavior, that does not consistute
permission for them to submit an I-D (with or without my name on it)
with thewords I
.
I believe I understand your point below that without understanding how
we ought to address problem 1, it is hard to be confident we are not
making it worse rather than better.
Yours,
Joel
On 8/2/2011 6:51 PM, John C Klensin wrote:
On 7/30/11 11:05 AM, Joel M. Halpern wrote:
It seems to me
It was once explained to me that a government agency that takes
information extraction seriously has several levels of testing for
language proficiency. For all (okay, maybe almost all, I do not have
the details) the languages they care about, the higher level testing
focuses on knowledge of
It seems to me that this does two things, both small but useful.
1) It makes a minor change in the advancement procedures so that they
are more reasonable. They may still not be sufficiently reasonable to
be used, but it improves them, and thereby improves the odds.
2) It is coupled to an
I think I understand your request taht we move beyond personal
anecdotes. In principle, I even agree with you.
However, when I try to act on that, I am stumped. I do not see any way
to evaluate say the last 2 years discusses to determine whether they
were more harmful or more helpful.
Any
After all, we moved RIPv1 to Historic when it was still widely
implemented, and used in many networks.
Yours,
Joel
On 7/19/2011 5:34 PM, Doug Barton wrote:
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive.
Replacing a widely used term (on the wire) with term that folks will
not understand does not seem to me personally to be a benefit.
In terms of this document, I do not see a problem with the usage as it
is. This is not a protocol document. The use of the current term in
this context seems
that in this
document it is used to refer to the message sent from one routing
process to another.
Apparently, this does not address Joe's concern.
Yours,
Joel
On 7/13/2011 2:24 PM, Wesley Eddy wrote:
On 7/13/2011 1:31 PM, Joel M. Halpern wrote:
Replacing a widely used term (on the wire) with term
, Wesley Eddy wrote:
On 7/13/2011 2:34 PM, Joel M. Halpern wrote:
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:
This text would note that it is a widely used term in IETF documents
:
On 7/13/2011 11:34 AM, Joel M. Halpern wrote:
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:
This text would note that it is a widely used term in IETF documents,
including many RFCs
is in scope.
it does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the
introductory scoping material, I would be happy to look at it.
Yours,
Joel
On 7/13/2011 5:08 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 1:58 PM, Joel M. Halpern wrote
-blown framework
document.
With that understanding, if there is an extra paragraph that will help
the introduction be clear about this, please send text.
Yours,
Joel
On 7/13/2011 7:02 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 2:26 PM, Joel M. Halpern wrote:
You wording seems to induce
I am not sure we are in sync, but it looks clsoe enough that proposed
introductory text would be veyr helpful at this point.
Yours,
Joel
On 7/13/2011 7:59 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 4:24 PM, Joel M. Halpern wrote:
I am not sure what you are asking.
KARP is never concerned
In performing a gen-art review of this document, which seems quite good
over all, I noticed a minor question, but did not remember to include it
in my gen-art review.
The defines a Tunnel-Identifier, identifying the end-point of a tunnel
within a node.
That identifier is defined as 16 bits.
. As such, it is not at all clear what the
reviewer is asking be clarified in this regard.
Yours,
Joel M. Halpern
On 6/30/2011 1:54 AM, Joe Touch wrote:
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
as well.
(The abstract needs to be replaced with an actual abstract. I had
thought that could be resolved in parallel with the IETF last call.)
Would that help, or would you have the same concerns?
Yours,
Joel
On 6/30/2011 9:52 AM, Joe Touch wrote:
Hi Joel,
On 6/30/2011 6:13 AM, Joel M. Halpern
Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths
Reviewer: Joel M. Halpern
Review Date: 23-June-2011
IETF LC End Date: 4-July-2011
IESG Telechat date: N/A
Summary: This document is close to ready for publication as a Proposed
The question is what necessary means in terms of willful violations of
specs. There are at least three cases I can understand, with different
implications:
There are cases where the existing spec, while it claims to apply,
actually is a bad idea. Then we need to document the problem and the
Requirements for Multicast AAA coordinated between
Content Provider(s) and Network Service Provider(s)
Reviewer: Joel M. Halpern
Review Date: 22-April-2011
IETF LC End Date: 5-May-2011
IESG Telechat date: N/A
Summary: This document is not ready for publication as an Informational RFC
Building from Bernard's note, it strikes me that if we are going to get
into device identity, we probably need to be communicating with (liaise)
3GPP/3GPP2, because they have very strong views on that topic. (Whether
one agrees or disagrees with their biases, talking to them seems important.)
I think this working group is a good idea.
My inclination would be to place it in the Applications area. It looks
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where
the relevant GEOLOC work has been done up till now.
Yours,
Joel M
...@ietf.org] On Behalf Of
Joel M. Halpern
Sent: Tuesday, April 19, 2011 10:50 AM
To: i...@ietf.org
Cc: p...@ietf.org; IETF discussion list
Subject: Re: [paws] WG Review: Protocol to Access White Space database
(paws)
I think this working group is a good idea.
My inclination would be to place
, quick to make a web
application solutions using XML or the like ... My concern is that
Applications imply that efficiency does not matter.
Paul
-Original Message-
From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of
Joel M. Halpern
Sent: Tuesday, April 19, 2011 10
Specifying the service interface a protocol provides (and what it
requires from other protocols) is often very useful. And is something
we have done in many cases.
Writing a set of subroutine definitions in some specific language is, in
my experience, usually far less useful.
As a related
of this draft. Please do not
conflate the two.
Yours,
Joel M. Halpern
On 3/24/2011 11:32 AM, Mykyta Yevstifeyev wrote:
Russ, all,
Another proposal as for your document. So, it fails to mention what are
the procedures for reclassification of Standards Track RFCs to Historic.
Therefore, I propose
There seems to be a minor but important inconsistency which leaves us
still not clearly addressing the interoperability issues.
The commentary text on the second standards level includes, when
commenting on the removal of the requirement for interoperability
testing reports:
subsumed by
PMIPv6 Localized Routing Problem Statement
Reviewer: Joel M. Halpern
Review Date: 7-March-2011
IETF LC End Date: 14-March-2011
IESG Telechat date: 17-March-2011
Summary: This document is close to ready for publication as an
Informational RFC.
Moderate issues:
The abstract is misleading
There are, in my opinion, two problems with Mr. Yevstifeyev's assertion
below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol is
in use on the public Internet, it is not always easy to detect. It may
be used in only
/
03.03.2011 17:11, Joel M. Halpern wrote:
There are, in my opinion, two problems with Mr. Yevstifeyev's
assertion below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol
is in use on the public Internet, it is not always easy
for verified
interoperability with the assumption of interoperability based on wide
deployment is an understandable compromise. I am not sure I like this
change, but I can live with it, which is good enough.
I do like the more relaxed wording on the removal of unused features.
Yours,
Joel M. Halpern
I would also point out that there is a difference between a contact for
a draft and a contact for a registry.
For a draft, there is always an individual contact. We frequently
accept that the only contact information is an email address.
For a registry, the contact information requirement
To be blunt, if someone is holding a bar BoF without making it primarily
a focus for discussion, they are missing the benefit of a Bar BoF. Yes,
we have a lot of bar bofs. And to the degree people are using these
as unapproved BoFs for presenting their ideas to a wider audience,
rather than
I think that there are some issues that are not being mentioned, but
which are important.
In general, there is the issue of impact. This takes many forms. But
the underlying effect is taht protocols which get widely deployed can
have distinctly negative impact on the net. Thus, for many
spend=t serously working on what the needs were, what the
deployments could be, and what the technology could look like, might
have given us a better path. (No, there is no guarantee. We could have
blown it anyway.)
Yours,
Joel M. Halpern
On 10/10/2010 6:41 PM, Dave CROCKER wrote:
On 10/10
shortly after the initial note was just beautiful. Thank you.
Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Two very different kinds of questions occur to me, reading this.
Firstly, the one really good thing about our current draft advancement
process is that we go look carefully and figure out what pieces of the
RFC have not been implemented. Given that this takes work, it is
unlikely to be
That is a well defined target metric.
It is defensible.
It is not the one the community has used up till now.
One could also aim to minimize total cost (or total pain).
Arguably, that would place all the meetings in california.
Up to till now, we have worked on a balance between those two
I would note that the Chinese entry from (that you have to hand over to
Immigration along with your visa and passport) specifically has a single
box labelled business/conference, which is clearly the applicable box
for attending the IETF.
Yours,
Joel
On Tue, August 24, 2010 7:09 pm, Edward Lewis
With regard to the major issue, in response to other comments, the
offending sentence (which is, as Ben observes, wrong, has been removed.
More precisely, there is now a note to the RFC Editor to remvoe the
sentence. If we need to revise the document for other reasons, we will
remove it
In hallway discussion about this, it was suggested to me that part of
the problem is that some folks can not figure out how to socialize their
ideas.
If ideas are really preliminary, sitting down with 4-6 other folks who
are skilled and informed on the particular topic to discuss the idea,
I do not think it is reasonable to ask people to commit for serving a
two year term on nomcom. Some folks have the energy and interest to do
so. Wonderful and thank you to them. But given that it is an intense
personnel selection process, I do not think expecting two years of
service for it
I think it may be important to better emphasis the difference between
formal BoFs and informal promotional meetings.
While Formal BoFs are not absolutely necessary for process purposes,
they are usually a good idea to help the IAB and IESG judge interest.
Process-wise, these informal barBoFs
on the committee. (The most inexperienced
committee on record, as far as we could tell, occurred when we had a
very good turnout for the nomcom volunteer pool, something I at least
really appreciate, and not an especially high turnout of experienced
people.)
Yours,
Joel M. Halpern
PS: When we updated
This note assumes that it was correct (not merely reasonable, as
reasonable folks can differ, and sometimes come to incorrect
conclusions) for someone using the day pass program to assume that said
attendance would count.
While some people have asserted that they find it obvious that it should
and
suggestions.
Regarding your suggestion on RFC type (change it from Informational to
PS), I believe it could not become PS since the other NSIS documents
(GIST QoS-NSLP) are Experimental.
Thanks again,
Jerry
--- On *Sat, 11/21/09, Joel M. Halpern /j...@joelhalpern.com/* wrote:
From
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
Just so some of the gallery is heard from on the list, I am presuming
that they are also counting the input from the survey.
I have no idea how many people responded to that, nor what they said.
I know that I indicated that I thought this was reasonable as long as
certain specific risks had
RFC 5620 calls for the appointment of an RFC Series Advisory Group, to
be appointed by the IAB, and a Independent Submissions Stream Editorial
Board (ISSEB for now), which serves at the pleasure of the ISE.
This was reviewed and approved by the community.
I presume with cognizance of the
can not come to agreement. (Note, I do not think that the degree
of review correlates with the degree of quality. That is a further
confusion about these notes.)
Yours,
Joel M. Halpern
Richard Barnes wrote:
Being a relatively short-term IETF participant, I lack the history that
many
Independent series.
Yours,
Joel M. Halpern
Jari Arkko wrote:
I would like to get some further input from the community on this draft.
But first some background. This draft was brought to a second last call
in June because several IESG members felt uncomfortable with the IESG
notes being used only
If I understand your note properly, your primary concern is that folks
will think that Independent submission are IETF products.
This is a fair concern.
But the same could be said all our experimental and informational RFCs.
Should we insist that all experimental and informational RFC, even
.
But the IESG review is for checking for conflicts with IETF work. It is
for reporting such conflicts. It is not a general review for does the
IETF like this work.
Yours,
Joel
Adam Roach wrote:
Joel M. Halpern wrote:
And given that these are Independent Submissions, they aren't supposed
If we really feel that the current approach does not make non-standards
clear enough, then we should address that for all experimental or
informational documents. It is basically unrelated to the Independent
Stream issue.
With regard to documents that are alternatives to existing IETF work,
Making the IESG note mandatory, even if that required IETF agreement,
would essentially give the IETf veto over the Independent stream. The
IESG would simply propose a note so extreme that no author would accept
it on their document. Given that I have seen proposed notes almost that
bad in
of difficulties in the converse.
If the ISE / RSE is unreasonable, the IAB will slap the editor and say
stop doing that. There is no equivalent process if we reverse the
structure.
Yours,
Joel M. Halpern
Ben Campbell wrote:
On Aug 31, 2009, at 9:04 PM, Joel M. Halpern wrote:
Making the IESG note
I would agree with Brian, but phrase it differently.
The Trust Legal Provisions document specifies exactly how the trust, and
people acting based on the trust, are doing things.
There are (at least) two kinds of changes that can occur.
1) There can be changes in policy, particularly policy as
1) There is no need to put licenses in the RFC at all. In fact, the
trust document says clearly that putting license text in RFCs is a bad idea.
2) The trust policy states that when code is extracted from an RFC, it
must be marked for attribution, and that the extractor can modify and
use the
I would consider that OBE. As I understand it, the trust procedures no
longer require those license statements in RFCs.
Yours,
Joel
Sean Turner wrote:
Julian Reschke wrote:
Sean Turner wrote:
...
In the documents I've worked on, it seems that they just want to put
the statement in the
While we can wordsmith the proposed resolution from now till doomsday,
what has been suggested seems good enough. I can certainly live with it.
Please, approve this document for publication as an BCP.
Yours,
Joel M. Halpern
The IESG wrote:
The IESG has received a request from an individual
NO, I believe he is suggesting something slightly different.
First, realize that the structure does not include any license statement
with the code in the RFC. That is covered by the boilerplate.
Second, the issue being addressed is the instruction to someone who
extracts the code from the
... they
have a right to expect a particular set of license conditions will apply
to their contribution. I can imagine being willing to release code under
BSD or GPL but not either based on my personal philosophy, etc.
Dave Morris
On Tue, 21 Jul 2009, Joel M. Halpern wrote:
NO, I believe he
, Jul 21, 2009 at 03:07:15PM -0400, Joel M. Halpern wrote:
And, even more specifically, it is only about how we describe that
license in the event that we want to change forward-going extractors.
I think it is exactly this premise that some are wondering about. Is
there any circumstance under
folks extracting large pieces of code to mark the RFC they
got it from, and when they took it. But that is up to them. The IETF
ought not mandate any more details than we absolutely have to about how
the code is extracted / used.
Joel
David Morris wrote:
On Tue, 21 Jul 2009, Joel M. Halpern
I don't think it means that.
Rather, what it does is the RfC says the code must include whatever
license the trust document says.
When the code is produced, that link is dereferenced, the license is
determined, and the license is inserted in the code.
No, no one can reasonably produce code
1 - 100 of 216 matches
Mail list logo
