Re: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP

[Stephane Bortzmeyer]

On Sun, Oct 21, 2007 at 09:57:37PM -0700,
 Peter Constable <[EMAIL PROTECTED]> wrote 
 a message of 80 lines which said:

> Also, "a further encoding of the encoding form" isn't going to be
> clear to readers.

It is a reference to a bad practice (used in URLs, for instance) to
encode twice (for instance in UTF-8, then in %xx escapes of the
bytes).

>   "However, when information about characters is to be processed by
>   people, reference to the Unicode code point is preferable to
>   encoded representations of the code point."

That's not more clear to me.


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

RE: Last Call: draft-klensin-unicode-escapes (ASCII Escaping ofUnicode Characters) to BCP

[Peter Constable]

From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED]
Sent: Monday, October 22, 2007 4:03 AM

>> Also, "a further encoding of the encoding form" isn't going to be
>> clear to readers.
>
> It is a reference to a bad practice (used in URLs, for instance) to
> encode twice (for instance in UTF-8, then in %xx escapes of the
> bytes).

The discussion in that section is about references to characters in general 
human-readable content, not in URLs. If that is what the wording is referring 
to, it's extremely opaque. If that's really what the authors intend to talk 
about, it should be explained -- and the section should be organized better so 
that it makes sense why that particular thing is being discussed.


>>   "However, when information about characters is to be processed by
>>   people, reference to the Unicode code point is preferable to
>>   encoded representations of the code point."
>
> That's not more clear to me.

How can it not be clear? Human-readable content is discussing a Unicode 
character and needs to refer to the character in some way. The whole point of 
this document is about how to refer. Since Unicode character identity is 
established by the name, the code point and the reference glyph, reference can 
be made using one of those three things. It appears to me that this document 
focuses on references based in some way on the code point: is not the key 
distinction between the code point itself and some encoded representation of 
the code point?



Peter Constable

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

Re: Third Last Call: draft-housley-tls-authz-extns

[Sam Hartman]

> "John" == John C Klensin <[EMAIL PROTECTED]> writes:

John> --On Thursday, 11 October, 2007 17:05 +0300
John> [EMAIL PROTECTED] wrote:

>> John C Klensin wrote:
>>> Assuming that this logic is reasonable (and, personally, I
>>> do), the question remains as to why the document deserves the
>>> special treatment of IESG sponsorship, rather than turning it
>>> over to the tender mercies and independent review of the
>>> independent submission process.  If nothing else, handling it
>>> as an independent submission would remove any suspicion that
>>> it was being given special treatment because one of its
>>> authors was IETF Chair.
>>> 
>>> I'm not strongly advocating that approach, just asking.
>>  The IANA rules in this case require a document approved by the
>> IESG; otherwise, independent submission would indeed be
>> preferable.

John> Strictly speaking, at least as I understand it, the IANA
John> rules (actually, the IETF rules imposed on the IANA) require
John> IESG approval of the registration, not IESG
John> approval/publication of the document.  If independent
John> submission would be preferable, nothing would prohibit
John> making that submission.  Then, assuming that the RFC Editor
John> tentatively agreed to publish, the document would be
John> submitted for RFC 3932 review and the IESG could sign off on
John> IANA registration at that point.

I do not believe the IESG should approve this IANA registration unless
there is community support to do so.


I think the argument that we should publish this document as-is for
the record makes no sense to me.  If we want to document an approach
so that it can be preserved as an archival record, then remove the
IANA registration, note the document specifies no code point and note
that it is being published to document an approach that did not
achieve consensus.

We should publish this document if we believe that it is reasonable
for people to use this protocol on the Internet and wish to enable
that.

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

Re: Third Last Call: draft-housley-tls-authz-extns

[John C Klensin]

--On Monday, 22 October, 2007 11:04 -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:

>...
> I do not believe the IESG should approve this IANA
> registration unless there is community support to do so.

> I think the argument that we should publish this document
> as-is for the record makes no sense to me.  If we want to
> document an approach so that it can be preserved as an
> archival record, then remove the IANA registration, note the
> document specifies no code point and note that it is being
> published to document an approach that did not achieve
> consensus.
> 
> We should publish this document if we believe that it is
> reasonable for people to use this protocol on the Internet and
> wish to enable that.

Given that this is a protocol document, and that there appears
to be no substantive experiment to be performed, I believe that
this is an argument for Proposed Standard --possibly with a
comment about the IPR situation in an appendix to the RFC -- or
no publication at all.   Even publication as Informational in
order to inform, and perhaps warn, people about something that
is being used does not meet the test of "believe that it is
reasonable for people to use ... and wish to enable that.

I don't know what position that would lead me to as to whether
or not it should be published, but that simple choice does
appear to me to be the logical conclusion.

  john


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

RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[John C Klensin]

--On Saturday, 20 October, 2007 19:15 -0700 Lawrence Rosen
<[EMAIL PROTECTED]> wrote:

>...
> But we're talking here about IETF standards, specifications
> that are prepared cooperatively and for free by talented
> individuals, companies and countries around the world. These
> specifications are intended for implementation everywhere to
> facilitate communications among us all. 
>...

Larry, with all due respect, if you substitute "ISO/IEC JTC1" or
"IEEE" (at least in the computer and communications areas for
both) in the above statements, they will still be true.  The
IETF is not particularly special in this regard.

To me, the question is simply one of whether trying to insist on
an unencumbered regime (whether for technical, economic, or
moral/ religious reasons) is important enough to justify
rejecting, a priori, any encumbered technology.  The IETF has
decided, repeatedly, that the answer is "no" and "we want to
look at these things on a case-by-case basis and evaluate the
tradeoffs".  While the part that follows the "no" differs, that
is the same conclusion reached by ISO, IEC, IEEE, and others.

If you want to pursue this further, I think it would be helpful
if you started supplying arguments that we haven't heard,
repeatedly, before.  Neither repeating those arguments, nor
making the assumption that the IETF agrees with your goals and
priorities, seems to be causing progress in this area.   What it
does accomplish is to get people to stop reading threads on this
subject, which further lowers the odds of getting IETF consensus
on a change in position.

Just my opinion, of course.
john


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

Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[Norbert Bollow]

John C Klensin <[EMAIL PROTECTED]> wrote:
> > But we're talking here about IETF standards, specifications
> > that are prepared cooperatively and for free by talented
> > individuals, companies and countries around the world. These
> > specifications are intended for implementation everywhere to
> > facilitate communications among us all. 
> >...
> 
> Larry, with all due respect, if you substitute "ISO/IEC JTC1" or
> "IEEE" (at least in the computer and communications areas for
> both) in the above statements, they will still be true.  The
> IETF is not particularly special in this regard.

I agree.  There are very good reasons to insist in all fora where
standards for protocols and data formats are developed that such
standards must not be patent-encumbered.

> To me, the question is simply one of whether trying to insist on
> an unencumbered regime (whether for technical, economic, or
> moral/ religious reasons) is important enough to justify
> rejecting, a priori, any encumbered technology.  The IETF has
> decided, repeatedly, that the answer is "no" and "we want to
> look at these things on a case-by-case basis and evaluate the
> tradeoffs".  While the part that follows the "no" differs, that
> is the same conclusion reached by ISO, IEC, IEEE, and others.

However the economic importance of insisting that standards must
not be patent-encumbered is increasing.  Therefore the decisions
of the past can not validly be accepted as strong arguments against
Larry's current initiative.

> If you want to pursue this further, I think it would be helpful
> if you started supplying arguments that we haven't heard,
> repeatedly, before.

Do you have a list of the arguments that you have heard so often
already that you're not interested in hearing them again?

Greetings,
Norbert.


-- 
Norbert Bollow <[EMAIL PROTECTED]>  http://Norbert.ch
President of the Swiss Internet User Group SIUGhttp://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org

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

RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[Lawrence Rosen]

John Klensin wrote:
> If you want to pursue this further, I think it would be helpful
> if you started supplying arguments that we haven't heard,
> repeatedly, before.  Neither repeating those arguments, nor
> making the assumption that the IETF agrees with your goals and
> priorities, seems to be causing progress in this area.   What it
> does accomplish is to get people to stop reading threads on this
> subject, which further lowers the odds of getting IETF consensus
> on a change in position.

John and others,

I have never made my proposal on ietf@ietf.org before. Indeed, I only
started contributing on this list recently. I'm pleased that YOU have heard
my arguments before in other venues, but there's no reason to assume that
others here have done so. I don't assume that IETF agrees with my goals or
priorities, nor perhaps do you have any reason to assume that the broader
IETF community agrees with you. 

I made my suggestion here to re-charter the IPR-WG after lurking on the list
for long enough to understand (I hope) the issues that this list considers
and the cultural environment in which those considerations occur, and long
after I became convinced that at least some of the people participating on
the much narrower IPR-WG list were culturally and philosophically unwilling
to listen to *any* arguments that IETF patent policy should be clarified or
changed. 

Your reference to the older and more stubbornly traditional ISO, IEC and
IEEE merely reminds me of important counter-examples, W3C and OASIS. Each
standards organization needs to articulate its patent policy in light of its
own mission and culture. IETF is a world-wide organization of volunteers
that standardizes much of the Internet. This is an *open* Internet,
available to all. Encumbering it with non-free patents is a danger that W3C
and OASIS have addressed. I suggest that IETF should address it too!

So please stand back a bit, John, and let the arguments on all sides be
fairly raised and rebutted before the participants on this list. Let's see
if consensus does arise here. Please don't assume, as I don't assume, that
everyone who has an opinion has already spoken up. 

I hope that others here will speak up.

***

Once again, specifically what I request is that we charter the IETF IPR-WG
to propose policies and procedures, consistent with the worldwide mission of
IETF, which will result in IETF specifications unencumbered by restrictive,
non-free patents.

***


> -Original Message-
> From: John C Klensin [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 22, 2007 11:15 AM
> To: [EMAIL PROTECTED]; ietf@ietf.org
> Subject: RE: A priori IPR choices [Re: Third Last Call:draft-housley-tls-
> authz-extns]
> 
> 
> 
> --On Saturday, 20 October, 2007 19:15 -0700 Lawrence Rosen
> <[EMAIL PROTECTED]> wrote:
> 
> >...
> > But we're talking here about IETF standards, specifications
> > that are prepared cooperatively and for free by talented
> > individuals, companies and countries around the world. These
> > specifications are intended for implementation everywhere to
> > facilitate communications among us all.
> >...
> 
> Larry, with all due respect, if you substitute "ISO/IEC JTC1" or
> "IEEE" (at least in the computer and communications areas for
> both) in the above statements, they will still be true.  The
> IETF is not particularly special in this regard.
> 
> To me, the question is simply one of whether trying to insist on
> an unencumbered regime (whether for technical, economic, or
> moral/ religious reasons) is important enough to justify
> rejecting, a priori, any encumbered technology.  The IETF has
> decided, repeatedly, that the answer is "no" and "we want to
> look at these things on a case-by-case basis and evaluate the
> tradeoffs".  While the part that follows the "no" differs, that
> is the same conclusion reached by ISO, IEC, IEEE, and others.
> 
> If you want to pursue this further, I think it would be helpful
> if you started supplying arguments that we haven't heard,
> repeatedly, before.  Neither repeating those arguments, nor
> making the assumption that the IETF agrees with your goals and
> priorities, seems to be causing progress in this area.   What it
> does accomplish is to get people to stop reading threads on this
> subject, which further lowers the odds of getting IETF consensus
> on a change in position.
> 
> Just my opinion, of course.
> john


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

Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[John C Klensin]

--On Monday, 22 October, 2007 21:57 +0200 Norbert Bollow
<[EMAIL PROTECTED]> wrote:

> John C Klensin <[EMAIL PROTECTED]> wrote:
>> > But we're talking here about IETF standards, specifications
>> > that are prepared cooperatively and for free by talented
>> > individuals, companies and countries around the world. These
>> > specifications are intended for implementation everywhere to
>> > facilitate communications among us all. 
>> > ...
>> 
>> Larry, with all due respect, if you substitute "ISO/IEC JTC1"
>> or "IEEE" (at least in the computer and communications areas
>> for both) in the above statements, they will still be true.
>> The IETF is not particularly special in this regard.

But the IETF seems to be singled out, in Larry's recent notes
and elsewhere, as the one body that needs to treat these things
differently.

> I agree.  There are very good reasons to insist in all fora
> where standards for protocols and data formats are developed
> that such standards must not be patent-encumbered.

But I see no evidence, at least in the ISO-level correspondence
that I follow, that they are being pursued with equal
persistence anywhere else.   I suspect that is because the
Member Bodies refuse to keep taking the question up over and
over again, and that, if the IETF had procedures similar or
equivalent to theirs, we would not be hearing about it again on
this list.

>> To me, the question is simply one of whether trying to insist
>> on an unencumbered regime (whether for technical, economic, or
>> moral/ religious reasons) is important enough to justify
>> rejecting, a priori, any encumbered technology.  The IETF has
>> decided, repeatedly, that the answer is "no" and "we want to
>> look at these things on a case-by-case basis and evaluate the
>> tradeoffs".  While the part that follows the "no" differs,
>> that is the same conclusion reached by ISO, IEC, IEEE, and
>> others.
> 
> However the economic importance of insisting that standards
> must not be patent-encumbered is increasing.  Therefore the
> decisions of the past can not validly be accepted as strong
> arguments against Larry's current initiative.

First, no persuasive evidence has been produced on this list
that this economic importance is, in fact, increasing.  The
economic importance may well be increasing for some categories
of encumbrances, or for some categories of implementations but I
don't believe a statement this broad can be justified.  

Second, while such increasing importance, were it to exist,
would justify a review of the policies, it doesn't automatically
lead to the conclusion that Larry (and presumably you) support.
In addition, "the past" isn't a long time here.   The IETF
policies were not established a decade or two ago and never
reviewed since: the question has been raised over and over again
as to whether the IETF, or various WGs, want to review the
policies, and the answer comes back "no".  So, even if the
economic importance has increased as you suggest, or other
arguments for unencumbered software exist, how often do you
think that requires review of the policies?  Once every few
years?  Once a year?  Once a month?  Once every two weeks until
you get your way and then never again?There comes a point
beyond which the raising of this position is a DoS attack on the
IETF's getting other work done.

I also note that we can easily get onto a slippery slope here.
Many companies view the GPL to be an encumbrance no less severe
than the patent policies of other companies.  Perhaps it is even
more severe because encumbrances associated with patents that
can be made to go away by the payment of money are less
complicated to deal with (if one is willing to spent the money)
than encumbrances under the GPS, which just don't go away.
Would you recommend that IETF not permit any materials that
might be encumbered under the GPL, etc.?

>> If you want to pursue this further, I think it would be
>> helpful if you started supplying arguments that we haven't
>> heard, repeatedly, before.
> 
> Do you have a list of the arguments that you have heard so
> often already that you're not interested in hearing them again?

I have seen nothing new in any of Larry's postings, or Simon's
postings, or other postings supporting their general positions,
in the last two months, so perhaps you could use that list as a
starting point.

best,
   john



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

Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[Sam Hartman]

For what it's worth, I'd like to write in general support of
re-evaluating several aspects of our patent policy.  I 'm not quite
writing in support of rechartering IPR at this time.  First, I think
they have critical copyright work to finish.  Second, I think that we
need to find a way to have the discussion in a productive forum.  I'm
not entirely sure a rechartered IPR working group would do that.

Here are some examples of questions I think it might be desirable to
consider:

* Establishing a clear category for some sort of
  open-source-compatible licensing terms.  We seem to think that
  royalty-free is good enough in our current policy, but that is
  demonstrably false.

* Evaluating whether our IPR policies are adequate to actually provide
  enforcement when people violate them.  What recourse do we have when
  people violate our policies; what recourse do users of our specs
  have?  Is this sufficient for our needs?  If we had different
  policies how much better would things be?



* Phil's proposal has been shot down prematurely in my opinion.  I
  agree that his current version would not fly.  However I do think
  there are working groups that could make conclusions about their
  patent policies and for which doing so would have helped the effort
  a lot.  I think sacred and dnsext are such working groups.  I think
  you could get consensus in krb-wg that patented technology is
  problematic in our standards.  However I'm not sure it would be
  useful as I don't think it would save much time.  I think
  considering whether there are aspects of Phil's proposals it would
  be useful to adopt might be useful.

Working through draft-housley-tls-authz-extns gave me a personal
significant lack of confidence in our patent policies and whether they
meet our goals and objectives.  I also wonder whether our goals and
objectives may have shifted somewhat since they were written.  However
I'm definitely uncomfortable with relying on our existing documents in
any real dispute.


In conclusion, I think Larry's proposed rechartering is an appropriate
contribution to this list.  While we may not ultimately decide to
follow his course of action, I think it an appropriate contribution.
I do not think he is attempting to DOS the process and believe he is
participating in good faith.

--Sam


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

Gen-ART review of draft-ietf-avt-topologies-06.txt

[Suresh Krishnan]

I am the assigned Gen-ART reviewer for
draft-ietf-avt-topologies-06.txt

For background on Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is very well written, an enjoyable read and is 
almost ready for publication except for a minor comment.


Minor
=

ASM is a term commonly used in multicast to mean Any Source Multicast 
(as opposed to Source Specific Multicast). The glossary of this draft 
redefines this to be "Asynchronous Multicast". Is this just a typo? 
Because from my reading of the draft all instances of this acronym 
actually use it in the context of Any Source Multicast. If it is just a 
typo it can be fixed with just an RFC-Editor note.


Cheers
Suresh



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

Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[Scott Kitterman]

On Monday 22 October 2007 16:27, John C Klensin wrote:

> I also note that we can easily get onto a slippery slope here.
> Many companies view the GPL to be an encumbrance no less severe
> than the patent policies of other companies.  Perhaps it is even
> more severe because encumbrances associated with patents that
> can be made to go away by the payment of money are less
> complicated to deal with (if one is willing to spent the money)
> than encumbrances under the GPS, which just don't go away.
> Would you recommend that IETF not permit any materials that
> might be encumbered under the GPL, etc.?

That sounds reasonable to me.  To promote global interoperability, standards 
need to be implementable throughout the internet ecosystem, both Free and 
Proprietary.  

Scott K

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

Re: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[Henning Schulzrinne]

I'm confused by this part of the discussion. How can a standard be  
encumbered by GPL? As far as I know, GPL does not prevent anyone from  
implementing a standard without any restrictions or fees, just  
possibly from using somebody else's code under certain conditions. I  
don't think that anybody is proposing that all implementations should  
be "free", in whatever sense of the word, just that free  
implementations can exist.


Thus, I consider this somewhat of a diversion.

Henning

On Oct 22, 2007, at 10:45 PM, Scott Kitterman wrote:


On Monday 22 October 2007 16:27, John C Klensin wrote:


I also note that we can easily get onto a slippery slope here.
Many companies view the GPL to be an encumbrance no less severe
than the patent policies of other companies.  Perhaps it is even
more severe because encumbrances associated with patents that
can be made to go away by the payment of money are less
complicated to deal with (if one is willing to spent the money)
than encumbrances under the GPS, which just don't go away.
Would you recommend that IETF not permit any materials that
might be encumbered under the GPL, etc.?


That sounds reasonable to me.  To promote global interoperability,  
standards
need to be implementable throughout the internet ecosystem, both  
Free and

Proprietary.

Scott K

___
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: A priori IPR choices [Re: Third Last Call:draft-housley-tls-authz-extns]

[Brian E Carpenter]

On 2007-10-23 16:20, Henning Schulzrinne wrote:
I'm confused by this part of the discussion. How can a standard be 
encumbered by GPL? As far as I know, GPL does not prevent anyone from 
implementing a standard without any restrictions or fees, just possibly 
from using somebody else's code under certain conditions. 


There's certainly a tricky point if code embedded in a standard
is explicitly subject to the GPL; that makes it effectively impossible
for a commercial implementor to use even fragments of that code
in a proprietary way.

I don't think 
that anybody is proposing that all implementations should be "free", in 
whatever sense of the word, just that free implementations can exist.


Thus, I consider this somewhat of a diversion.


Well, there's an inverse claim that some of the IETF's current rules
make it impossible to use material extracted from RFCs in open source
under certain OS licenses. But I agree that these copyright issues are
distinct from patent issues. The latter concern whether an implementor
can put code under a given OS license at all, depending on the exact
form of patent licence available. Not all OS licenses have this
problem, however.

Brian


Henning

On Oct 22, 2007, at 10:45 PM, Scott Kitterman wrote:


On Monday 22 October 2007 16:27, John C Klensin wrote:


I also note that we can easily get onto a slippery slope here.
Many companies view the GPL to be an encumbrance no less severe
than the patent policies of other companies.  Perhaps it is even
more severe because encumbrances associated with patents that
can be made to go away by the payment of money are less
complicated to deal with (if one is willing to spent the money)
than encumbrances under the GPS, which just don't go away.
Would you recommend that IETF not permit any materials that
might be encumbered under the GPL, etc.?


That sounds reasonable to me.  To promote global interoperability, 
standards

need to be implementable throughout the internet ecosystem, both Free and
Proprietary.

Scott K

___
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



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

An example of what is wrong with the IETF's IPv6 documentation

[michael.dillon]

The following thread from ARIN's Public Policy Mailing List is an
example of what is wrong with the IETF's documentation of IPv6. People
are struggling to understand just how IPv6 works, not at the
implementation level of detail, but at a higher level. 

What is mandatory, what is optional? What are the basic principles, what
is the fundamental architecture?

Some people argue that IPv6 is merely IPv4 with more bits, therefore all
the rules and constraints of IPv4 must necessarily be applied. There is
no IETF document that provides the right kind of high-level view of
IPv6, and no document that provides guidelines for RIRs.

In the absence of such guidance, it appears as though people who plan to
alloocate /120's to customers are right, and Brian Dickson is the
authoritative voice of the IETF who understands IPv6 most clearly.

Most people who make decisions about addressing plans in the RIRs or in
ISPs, do not have the time to wade through dozens of RFCs trying to
figure out what is NOT DEPRECATED and what is the IPv6 STANDARD.

I believe that the 6MAN group should add to its charter two documents:
IPv6 guidelines for RIRs and IPv6 Overview for ISPs.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Brian Dickson
> Sent: 22 October 2007 22:42
> To: ARIN PPML
> Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm
> 
> Leo Bicknell wrote:
> > In a message written on Mon, Oct 22, 2007 at 09:31:36AM 
> -0400, Azinger, Marla wrote:
> >   
> >> 3177 is a recommendation from 2001 and not a standar of any kind.
> >> 
> >
> > I'm afraid many people are not looking at the right RFC's and/or 
> > considering what all needs to be changed if the /64 
> boundary is to be 
> > updated.  I'm fairly sure this is not an exhaustive list, /64 is 
> > referenced in many locations in different IPv6 RFC's, many of which 
> > are standards track.
> >
> > * http://www.faqs.org/rfcs/rfc2373.html
> >   "IP Version 6 Addressing Architecture"
> >   Status: Standards Track
> >
> >   Section 2.5.1: "Interface IDs are required to be 64 bits long..."
> >
> >   Section 2.5.7: Aggregatable Global Unicast Addresses
> >
> >   Section 2.5.8: Local-Use IPv6 Unicast Addresses
> >
> >   
> RFC 2373 was obsoleted by 3531 which was obsoleted by 4291.
> 2.5.8 is gone, but AGUA is still roughly the same (all but 
> 000 require use of EUI-64 modified), and ditto 2.5.1
> > * http://www.faqs.org/rfcs/rfc2374.html
> >   "An IPv6 Aggregatable Global Unicast Address Format"
> >   Status: Standards Track
> >
> >   Section 3.1 makes it clear the lower 64 bits are an interface
> >   identifier for
> >
> >   I also point out section 3.4 makes a recomendation we 
> continue to use
> >   a slow start method:
> >
> > It is recommended that
> > organizations assigning NLA address space use "slow 
> start" allocation
> > procedures similar to [RFC2050].
> >
> >   
> 2374 was obsoleted by 3587.
> > * http://www.faqs.org/rfcs/rfc2450.html
> >   "Proposed TLA and NLA Assignment Rule"
> >   Status: Informational
> >
> >   Section 3: IPv6 Aggregatable Global Unicast Address Format
> >
> >   
> This bit was itself in RFC 2374, which was obsoleted by RFC 3587.
> > * http://www.faqs.org/rfcs/rfc2460.html
> >   "Internet Protocol, Version 6 (IPv6) Specification"
> >   Status: Standards Track
> >
> >   Section 3: Specifically referrs to 2373 (ADDRARCH)
> >   
> 4291  obsoletes 3531 which obsoleted 2373.
> 
> (I don't know why 2460 hasn't been updated with the new references...)
> > * http://www.rfc-editor.org/rfc/rfc3177.txt
> >   "IAB/IESG Recommendations on IPv6 Address Allocations to Sites"
> >   Status: Informational
> >
> >   Section 3: Recomendations
> >   
> This was informational only, from 2001, and IMHO no longer as 
> relevant as it once was.
> 
> So, by my count, that is 4291 and 3587.
> 
> My IETF draft also lists 2464 (Ethernet),  4941 (privacy), 
> and 4862 (autoconfiguration).
> Most other IPv6 RFCs inherit from those few, and mostly the 
> choice is rather axiomatic.
> Two small changes, basically, in a backward-compatible 
> manner, is meant to be as minimally-disruptive as is possible.
> (Think surgery to remove a burst appendix or inflamed tonsils.)
> 
> Anyone interested can see the draft at:
> http://www.ietf.org/internet-drafts/draft-dickson-v6man-new-au
> toconf-00.txt
> 
> My draft even includes the necessary patch for Linux, about 
> 17 lines in total, mostly the result of the necesssary line 
> length provisions for an RFC. (It was 10 lines
> originally.)
> 
> Brian
> ___
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List ([EMAIL PROTECTED]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at [EMAIL PROTECTED] if you 
> experience any issues.

I don't think it is 

Re: secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt

[Tom Yu]

> "Bob" == Bob Briscoe <[EMAIL PROTECTED]> writes:

Bob> Tom,
Bob> You're analysis of the impact on the ECN nonce is accurate. Below is
Bob> our reasoning for not including the ECN nonce capability in this
Bob> proposal...

[...]

Thanks for the detailed rationale of your decision to not include the
ECN nonce.  Given that the question of detecting disruption of
end-to-end ECN signaling within an MPLS domain occurred to me from the
mention of RFC3540 in the Security Considerations, other readers of
this document may have similar questions.  I suggest that you add a
sentence or two to the Security Considerations summarizing your
decision to exclude the ECN nonce capability from this particular
proposal.  However, I will not object to the passage of this document
if you choose not to include such a summary.

---Tom

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

Re: Seeking ICANN Nomcom 2008 candidate

[Joe Abley]

On Sun, 30 Sep 2007 15:59:28 +0200, Olaf Kolkman wrote:

On behalf of the IETF, the IAB has to deliver one of the 17 voting  
members to the ICANN Nomcom for 2008.


Now that the selections from the 2007 ICANN Nomcom have been  
announced [1] we would like to ask the community for volunteers to  
serve on the 2008 ICANN Nomcom. The IAB invites volunteers to reply  
within 10 days, as that allows participation in the first meeting  
in early November (see below). If you are interested, please send  
us a short e-mail with your motivation and information concerning  
your familiarity with the IETF and ICANN.


The IAB has selected Ole Jacobsen as the IETF member of the 2008  
ICANN Nomcom.


We would like to thank all those who volunteered.

For the IAB,


Joe Abley
(IAB execd)

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