Re: Use of "unassigned" in IANA registries

[Phillip Hallam-Baker]

On Tue, Jan 18, 2011 at 2:46 AM, Lars Eggert  wrote:

> Hi,
>
> On 2011-1-17, at 1:23, Phillip Hallam-Baker wrote:
> > If people think that IANA is a tool they can use to impose their own
> > personal political agenda on the Internet, they are mistaken.
>
> that isn't the point of this thread.
>
> The point of IANA assignment is to avoid conflicting codepoint usage.
> Squatting on codepoints defeats this goal.
>

But it meets the goal of the people squatting. Is there any reason to think
that changing the name of the code points is going to make a difference?


I know of about 5 or so TCP option numbers that are being squatted on at the
> moment (there are likely more). I've been in discussion with the folks who
> are squatting, and in all cases the story was either "we were going to ask
> for assignment but it got forgotten" or "oh, you mean unassigned doesn't
> mean it's free for the taking?"
>

Those sound like excuses to me rather than reasons.

I am currently applying for a DNS RR code assignment. More than one person
involved suggested that we should just assign the RR code ourselves by fiat
because they didn't want to wait six weeks for a review.

My name is on the draft so we have applied for an assignment. But now that
six weeks have passed we have a major industry meeting next week that is to
discuss the proposal (amongst others) as part of a DNSSEC deployment effort
and there has been no response.


Using a term other than "unassigned" might prevent some instances of the
> latter.


I don't see how changing the name is going to affect behavior for the
positive here. If you do succeed in confusing people as to which numbers are
unassigned and which are not it is going to increase the risk of a
collision.


If five people are experimenting with TCP options and this is not causing
collisions, what is the problem?


-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Use of "unassigned" in IANA registries

[Spencer Dawkins]

Phillip,

Lars can speak for himself, but what I THOUGHT he was talking was changing the 
phrase "unassigned" to something like "reserved for future assignment". 

That made sense to me...

Spencer
  - Original Message - 
  From: Phillip Hallam-Baker 
  To: Lars Eggert 
  Cc: Iljitsch van Beijnum ; paul.hoff...@vpnc.org ; ietf@ietf.org 
  Sent: Tuesday, January 18, 2011 7:51 AM
  Subject: Re: Use of "unassigned" in IANA registries





  On Tue, Jan 18, 2011 at 2:46 AM, Lars Eggert  wrote:

Hi,


On 2011-1-17, at 1:23, Phillip Hallam-Baker wrote:
> If people think that IANA is a tool they can use to impose their own
> personal political agenda on the Internet, they are mistaken.


that isn't the point of this thread.

The point of IANA assignment is to avoid conflicting codepoint usage. 
Squatting on codepoints defeats this goal.



  But it meets the goal of the people squatting. Is there any reason to think 
that changing the name of the code points is going to make a difference?




I know of about 5 or so TCP option numbers that are being squatted on at 
the moment (there are likely more). I've been in discussion with the folks who 
are squatting, and in all cases the story was either "we were going to ask for 
assignment but it got forgotten" or "oh, you mean unassigned doesn't mean it's 
free for the taking?"



  Those sound like excuses to me rather than reasons.


  I am currently applying for a DNS RR code assignment. More than one person 
involved suggested that we should just assign the RR code ourselves by fiat 
because they didn't want to wait six weeks for a review.


  My name is on the draft so we have applied for an assignment. But now that 
six weeks have passed we have a major industry meeting next week that is to 
discuss the proposal (amongst others) as part of a DNSSEC deployment effort and 
there has been no response.




Using a term other than "unassigned" might prevent some instances of the 
latter.


  I don't see how changing the name is going to affect behavior for the 
positive here. If you do succeed in confusing people as to which numbers are 
unassigned and which are not it is going to increase the risk of a collision.




  If five people are experimenting with TCP options and this is not causing 
collisions, what is the problem?




  -- 
  Website: http://hallambaker.com/




--


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

Re: Use of "unassigned" in IANA registries

[Lars Eggert]

Hi,

On 2011-1-18, at 15:51, Phillip Hallam-Baker wrote:
> >Using a term other than "unassigned" might prevent some instances of the 
> >latter.
> 
> I don't see how changing the name is going to affect behavior for the 
> positive here. If you do succeed in confusing people as to which numbers are 
> unassigned and which are not it is going to increase the risk of a collision.

huh? The purpose here is to make it *clearer* that assignment is needed.

> If five people are experimenting with TCP options and this is not causing 
> collisions, what is the problem?

Have you read my original email? It *is* going to cause collisions.

Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Use of "unassigned" in IANA registries

[Lars Eggert]

On 2011-1-18, at 15:58, Spencer Dawkins wrote:
> Lars can speak for himself, but what I THOUGHT he was talking was changing 
> the phrase "unassigned" to something like "reserved for future assignment". 

Exactly.

Lars


> 
> That made sense to me...
> 
> Spencer
>  - Original Message - 
>  From: Phillip Hallam-Baker 
>  To: Lars Eggert 
>  Cc: Iljitsch van Beijnum ; paul.hoff...@vpnc.org ; ietf@ietf.org 
>  Sent: Tuesday, January 18, 2011 7:51 AM
>  Subject: Re: Use of "unassigned" in IANA registries
> 
> 
> 
> 
> 
>  On Tue, Jan 18, 2011 at 2:46 AM, Lars Eggert  wrote:
> 
>Hi,
> 
> 
>On 2011-1-17, at 1:23, Phillip Hallam-Baker wrote:
>> If people think that IANA is a tool they can use to impose their own
>> personal political agenda on the Internet, they are mistaken.
> 
> 
>that isn't the point of this thread.
> 
>The point of IANA assignment is to avoid conflicting codepoint usage. 
> Squatting on codepoints defeats this goal.
> 
> 
> 
>  But it meets the goal of the people squatting. Is there any reason to think 
> that changing the name of the code points is going to make a difference?
> 
> 
> 
> 
>I know of about 5 or so TCP option numbers that are being squatted on at 
> the moment (there are likely more). I've been in discussion with the folks 
> who are squatting, and in all cases the story was either "we were going to 
> ask for assignment but it got forgotten" or "oh, you mean unassigned doesn't 
> mean it's free for the taking?"
> 
> 
> 
>  Those sound like excuses to me rather than reasons.
> 
> 
>  I am currently applying for a DNS RR code assignment. More than one person 
> involved suggested that we should just assign the RR code ourselves by fiat 
> because they didn't want to wait six weeks for a review.
> 
> 
>  My name is on the draft so we have applied for an assignment. But now that 
> six weeks have passed we have a major industry meeting next week that is to 
> discuss the proposal (amongst others) as part of a DNSSEC deployment effort 
> and there has been no response.
> 
> 
> 
> 
>Using a term other than "unassigned" might prevent some instances of the 
> latter.
> 
> 
>  I don't see how changing the name is going to affect behavior for the 
> positive here. If you do succeed in confusing people as to which numbers are 
> unassigned and which are not it is going to increase the risk of a collision.
> 
> 
> 
> 
>  If five people are experimenting with TCP options and this is not causing 
> collisions, what is the problem?
> 
> 
> 
> 
>  -- 
>  Website: http://hallambaker.com/
> 
> 
> 
> 
> --
> 
> 
>  ___
>  Ietf mailing list
>  Ietf@ietf.org
>  https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Use of "unassigned" in IANA registries

[Phillip Hallam-Baker]

On Tue, Jan 18, 2011 at 8:58 AM, Spencer Dawkins
wrote:

>  Phillip,
>
> Lars can speak for himself, but what I THOUGHT he was talking was changing
> the phrase "unassigned" to something like "reserved for future assignment".
>
> That made sense to me...
>

That would work IF the reason this is happening is that people don't
understand that unassigned means reserved for future assignment.

But I rather suspect that the reason that this is happening is that people
know full well that there is a process and choose to ignore it because they
either can't be bothered to put up with the hassle or don't think that the
application will be accepted.


At the moment we do in fact have code points that are reserved as distinct
from being 'unassigned' and this is done because it is known that use of
that code point will cause a collision. Often because the code point was
hijacked.

For example the DNS code points for Apple's Bonjour protocol are reserved
rather than assigned.

SRV code points are an even bigger mess because there isn't even a proper
registry to enter them in.


I think it is rather more likely that the root cause here goes back to the
fact that the old three track standard process has broken down and the
criteria for acceptance as a PROPOSED standard are now essentially those for
DRAFT.

One of the reasons for having a low bar for initial drafts was that they
were necessary to get the required code point assignments.


Lars writes:

>> If five people are experimenting with TCP options and this is not causing
collisions, what is the problem?

>Have you read my original email? It *is* going to cause collisions.

This type of behavior certainly could cause collisions. But that seems to be
a risk that the people who engage in that behavior prefer to take rather
than apply for an assignment.


What I am saying here is that people need to be very clear as to what the
objectives they are trying to achieve here and make sure that they do not
overstep the mark.

If the only priority is to prevent collisions, then it is really easy to
avoid problems, just open the registry first come first served.

For many lower level registries that is not an option because there is a
real risk of code point exhaustion. That is particularly true with some of
the deep down one byte codes. But that is relatively manageable.

What creates real problems and puts those objectives at risk is when control
of the registry is seen as a means of ensuring that nobody can deploy
proprietary code or encumbered technology or something that someone feels
should really be built on the basis of their little pet project so that it
gets deployed and used.


There are plenty of cliques who try to engage in that particular type of
behavior and far too few people who have the courage to stand up to them and
call them out when they do so.

-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Use of "unassigned" in IANA registries

[Lars Eggert]

Hi,

On 2011-1-18, at 16:32, Phillip Hallam-Baker wrote:
> That would work IF the reason this is happening is that people don't
> understand that unassigned means reserved for future assignment.

that *is* the reason, for at least those cases that I have been involved in.

> But I rather suspect that the reason that this is happening is that people
> know full well that there is a process and choose to ignore it because they
> either can't be bothered to put up with the hassle or don't think that the
> application will be accepted.

Suspect all you want, but it doesn't match my experience.

> SRV code points are an even bigger mess because there isn't even a proper
> registry to enter them in.

We're very close to fixing this: 
http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports

> I think it is rather more likely that the root cause here goes back to the
> fact that the old three track standard process has broken down and the
> criteria for acceptance as a PROPOSED standard are now essentially those for
> DRAFT.

RFC2026 has almost nothing to do with IANA allocation procedures. (The only 
relation is that some registries require a Standards Action, but even then it 
is irrelevant which level of the standards track the RFC is on. And yes, it's 
somewhat more difficult to have a Standards Action occur than passing the bar 
for the other RFC5226 policies, but then again, few registries actually need a 
Standards Action.)

Lars



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Use of "unassigned" in IANA registries

[Eric Rosen]

Phillip> But I rather suspect that the reason that this is happening is that
Phillip> people know full well that there is a process and choose to ignore
Phillip> it because they either can't be bothered to put up with the hassle
Phillip> or don't think that the application will be accepted.

Lars> Suspect all you want, but it doesn't match my experience.

Phillip's suspicion certainly matches my experience over the past 15 years,
and I've even done my own share of codepoint squatting.  He is also correct
to state that many folks try to use control over the codepoint space as part
of their competitive marketing strategy.  The only way to avoid collisions
due to "squatting" is to adopt a policy that all codepoint fields be large
enough so that a significant number of codepoints are available for FCFS
allocations.


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

Re: Is the xml2rfc mailing list working?

[Xavier Marjou]

Hi,

I experimented the same problem this morning. I filled the
http://lists.xml.resource.org/mailman/listinfo/xml2rfc form twice but I did
not receive any requesting confirmation mail in my mailbox.

Cheers,
Xavier

On Fri, Jan 14, 2011 at 10:22 PM, Worley, Dale R (Dale)
wrote:

> I've attempted to subscribe to the xml2rfc mailing list several times in
> the last month, but never gotten a response.  Is it still working?
>
> Dale
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Use of "unassigned" in IANA registries

[Lars Eggert]

On 2011-1-18, at 17:15, Eric Rosen wrote:
> The only way to avoid collisions
> due to "squatting" is to adopt a policy that all codepoint fields be large
> enough so that a significant number of codepoints are available for FCFS
> allocations.

That's certainly a suggestion we should follow for new registries, but 
unfortunately doesn't help us with existing ones.

Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Cell data connectivity in CZ

[Michal Krsek]

Dear all,
please note we have three relevant cell operators in Prague.

O2 - http://www.o2.cz/osobni/en/mobile_internet/
(closest shop @ "Sokolovská 17, Praha" 
http://maps.google.com/maps?f=q&source=s_q&hl=cs&q=o2&sll=50.090418,14.440632&sspn=0.004374,0.005295&ie=UTF8&t=h&rq=1&ev=p&split=1&radius=0.14&hq=o2&hnear=&ll=50.090968,14.440198&spn=0.004374,0.005295&z=18 
)


T-Mobile - 
http://www.t-mobile.cz/web/en/internet/webnwalk-tariffs-and-add-ons

same locality as O2

Vodafone - https://www.vodafone.cz/live_en/index.htm
(closest schop @ náměstí Republiky 1078/1, Praha)

I think most of them cover area neighboring Prague Hilton and Prague 
city center by UMTS network in 2.1 Ghz band together with 1800/900 Mhz 
GPRS/EDGE. All of the operators have USB modem for purchase but I'm 
afraid drivers are Windows only.


I'm visiting shop selling O2 and T-Mobile in next few weeks to make sure 
they can support non-czech customers with non-windows based devices :-) 
Vodafone is located in a big shopping center crowded by tourists.


I can do one more favor for community. O2 has an promo proposal for 
prepaid SIM card for CZK 95 (slightly lower value than 5 newly printed 
USD). This card covers one week (seven days) for free Internet and I 
regullary use them as "use and discard". I can buy a bunch of these 
cards and make them available on basis of demand from the community for 
not-for profit. So if you like to use this sim card, just drop me 
PERSONAL e-mail message (do not reply to the list).


Regards
Michal Krsek

P.S: With those with iPad devices please note Czech mobile operators do 
NOT provide micro SIM cards.


P.P.S: I'm resending this message later to 80attendees list.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Scalable Operation of Address Translators with Per-Interface Bindings) to Proposed Standard

[Marc Blanchet]

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 Operation of Address Translators with Per-Interface Bindings'
 as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-10. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-arkko-dual-stack-extra-lite/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-arkko-dual-stack-extra-lite/


No IPR declarations have been submitted directly on this I-D.
___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce



--
=
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

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

Re: Gen-ART LC review of draft-ietf-roll-routing-metrics-14

[JP Vasseur]

Thanks Roni.

On Jan 16, 2011, at 2:07 PM, rontlv wrote:

> Hi JP,
> Thanks, I am OK with all your responses
> Roni
>  
> From: JP Vasseur [mailto:j...@cisco.com] 
> Sent: Friday, January 14, 2011 8:44 AM
> To: Roni Even
> Cc: gen-...@ietf.org; draft-ietf-roll-routing-metrics@tools.ietf.org; 
> IETF-Discussion list
> Subject: Re: Gen-ART LC review of draft-ietf-roll-routing-metrics-14
>  
> Hi Roni,
>  
> Thanks for your thorough review - please see in line JP>
>  
> On Dec 20, 2010, at 7:14 PM, Roni Even wrote:
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> .
>  
> Please resolve these comments along with any other Last Call comments you may 
> receive.
>  
> Document: draft-ietf-roll-routing-metrics-14
> Reviewer: Roni Even
> Review Date:2010–12–20
> IETF LC End Date: 2011–1–5
> IESG Telechat date:
>  
> Summary: This draft is almost ready for publication as an Standard track RFC.
>  
> Major issues:
> No Major issues
>  
> Minor issues:
>  
> 1.  In section 2.1 after figure 1 you specify the different fields. Please 
> specify the size in bits of the flags field the A-field and the prec field.
>  
> JP> Done.
> 
> 
> 2.  In section 2.1 in example 1 how is it known that all nodes MUST be main 
> powered.
>  
> JP> In this example, we first explain how the headers flags are determined. 
> To help clarify I modified the text:
>  
> OLD:
>  
> As far as the constraint is concerned, if the constraint signalled in the DIO 
> message is not satisfied, the advertising node is just not selected as a 
> parent by the node that processes the DIO message.
>  
> NEW:
>  
> As far as the constraint is concerned, the object body will carry a node 
> energy constraint object defined in Section 3.1 indicating that nodes must be 
> mains-powered: if the constraint signalled in the DIO message is not 
> satisfied, the advertising node is just not selected as a parent by the node 
> that processes the DIO message.
> 
> 
> Do you need to provide a value to prec field?
>  
> JP> As indicated earlier, the Prec field is only useful when a DAG Metric 
> Container contains several Routing Metric objects. In this example, there is 
> just one metric (the node energy is a constraint).
> 
> 
> 3.  In section 3.1 and throughout the document when you define the different 
> object you have “recommended value=xx”. I think that since this draft defines 
> the table and create the initial table in the IANA consideration section 
> these are the actual values. So maybe say that these are the actual values as 
> specified in section 6 (6.1)
>  
> JP> We added "recommended values" until IANA confirms.
> 
> 
> 4.  In section 3.1 the flag field – how many bits, specify.
>  
> JP> Done.
> 
> 
> 5.  In section 3.2 figure 4 shows a flag field, how many bits, what is the 
> value.
>  
> JP> Done.
> 
> 
> 6.  In section 6 according to rfc5226 “IETF consensus” is now “IETF review”.
>  
> JP> Fixed.
> 
> 
> 7.  In section 6.1 you should say that the table has the initial values and 
> add which numbers are available for allocation.
>  
> JP> Done.
> 
> 
> 8.  In section 6.2 what values are available for allocation.  Also say that 
> currently the table is empty.
>  
> JP> Done.
> 
> 
> 9.  In section 6.2 is there a reason to create an empty table. Why not do it 
> when there is a request to define a TLV
>  
> JP> Just to have the registry already in place. There is more than likely be 
> TLVs defined in a very near future. This also allows to make sure that all 
> TLVs have the same structure.
>  
> 10.In section 6.3, are there more values allowed, can they be allocated. If 
> not why have it managed by IANA.
>  
> JP> The A field is a 3-bit field and there are currently 4 defined values.
> 
> 
> 11.After the table in section in section 6.3 there is a request to create 
> another table. Maybe it should be in a separate section.
>  
> JP> This is just because we put all registries belonging to the Routing 
> Metric/Constraint Common Header in the same section.
> 
> 
> 12.In section 6.3 “New bit numbers may be allocated”, how many bits are 
> available.
>  
> JP> The text was misplaced, thanks.
> 
> 
> 13.The same paragraph in section 6.3 also talks about the registration 
> policy, is it different from the one that is common in section 6, why specify 
> it again. Also look at comment 6
>  
> JP> This was a duplicate. Fixed.
> 
> 
> 14.Comment 12 and 13 are also true for section 6.4 and 6.5.
>  
>  
> JP> Fixed too.
> 
> 
>  
>  
> Nits/editorial comments:
>  
> 1.  In section first paragraph “object” should be “object”
> 2.  In section 4.3.2 first paragraph “wich” should be “which”
>  
>  
> JP> Fixed.
>  
> Many Thanks. These changes are all incorporated in revision 15.
>  
> JP.
> 
> 
>  
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>  

Re: Use of "unassigned" in IANA registries

[Martin Rex]

Lars Eggert wrote:
> 
> On 2011-1-18, at 17:15, Eric Rosen wrote:
> > The only way to avoid collisions
> > due to "squatting" is to adopt a policy that all codepoint fields
> > be large enough so that a significant number of codepoints are
> > available for FCFS allocations.
> 
> That's certainly a suggestion we should follow for new registries, but
> unfortunately doesn't help us with existing ones.


A possibility for existing registries would be to allow for optimistic
reservation.  e.g. allow WG conensus to request a reservation of a code
point for registries that require standards action, which would cause
IANA to change a code point from "unassigned" to "reserved" (or "tentative")
for a certain amount of time.

It depends on the priorities: is it better to have a clean and strictly
sequential official assignments of code points (with collisions created
by those who do not want to wait), or is it better to prevent
collisions at the risk of somewhat scattered final assignments appearing
in the registry, and potential collisions with abandoned proposals when
the pool of available code points is getting exhausted.

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Use of "unassigned" in IANA registries

[t.petch]

- Original Message -
From: "Lars Eggert" 
To: "Spencer Dawkins" 
Cc: "Iljitsch van Beijnum" ; "Phillip Hallam-Baker"
; ; 
Sent: Tuesday, January 18, 2011 3:02 PM

On 2011-1-18, at 15:58, Spencer Dawkins wrote:
> Lars can speak for himself, but what I THOUGHT he was talking was changing the
phrase "unassigned" to something like "reserved for future assignment".

Exactly.


Which, presumably, would be in a BCP updating RFC5226 which only allows for

  Private Use:
  Experimental:
  Reserved:  Not to be assigned.
  Unassigned: Unused and available for assignment via documented  procedures.

Tom Petch



Lars

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

this seems to have become broken some time back

[bill manning]

and I guess I am the only one who might still use it - but regardless, if its 
broken, it should be fixed


to wit:


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-(ofthehour).txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


Mail Attachment
Description: Binary data
___
I-D-Announce mailing list
i-d-annou...@ietf.org


  seems that the mail attachment (MIME) is no longer a copy of the draft in 
question, its a dummy text block.

We are sad.

--bill___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [DNSOP] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard

[Eric Brunner-Williams]

There are label segments that have semantics.

The "--" violation, prepended by something, "^xn", where "^" indicates 
a label boundary, to indicate a (the current) "IDN" processing.


Bytes within a label with values in excess of 127.

Off hand I can't think of anything else (that is intentional). Along 
the accidental sort-of-intended mumble access of forensic engineering 
are terminating (TLD) labels that brain-dead dead-ware interprets (if 
anyone living were to ask it) character representations of digit 
sequences as v4 addresses that currently has the pants scared off of 
ICANN and some folks from this side of the policy|tech divide.


Everything else seems to just be intentional carve outs of string 
spaces, suited, if there is a purpose, to the (defunct) User Services 
Area Directorate and its inform-the-community mission that "example" 
is not a means to repeat for the bazillionth time the flagship brand 
of Verisign.


.local has sufficient meaning to care about.

John Levin's draft covers some "don't pretend you're ARPA" ground, 
which is a useful restriction on what appears in the IANA root (and 
any other used by every user in China) and in SLDs, assuming that a 
means other than persuasion is available to inform both 
auctions-are-good gTLD operators and ICANN-is-irrelevant ccTLD 
operators that some restrictions are beneficial.


The chief defect of Stewart's draft is that it makes an analogy to the 
semantics of addressing, and postulates a pseudo-technical set of 
implementation responsibilities, and fails to mention ICANN, which has 
some coordination mission.


What isn't a layer 9 is worth documenting. What is at layer 9 should 
be documented as being at layer 9.


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

Re: this seems to have become broken some time back

[Joe Abley]

On 2011-01-18, at 15:03, bill manning wrote:

> and I guess I am the only one who might still use it - but regardless, if its 
> broken, it should   seems that the mail attachment (MIME) is no longer a 
> copy of the draft in question, its a dummy text block.

I don't think it was ever a copy of the draft in question; it has been an 
RFC1873-compliant Message/External-Body section as long as I have been 
watching. To draw from another random example that came through recently on 
i-d-announce:

> Content-Type: Message/External-body;
>   name="draft-ietf-idr-bgp-identifier-13.txt"; site="ftp.ietf.org";
>   access-type="anon-ftp"; directory="internet-drafts"

I've never used a mail client that knows what to do with that, though.


Joe

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

Re: Use of "unassigned" in IANA registries

[Phillip Hallam-Baker]

On Tue, Jan 18, 2011 at 10:15 AM, Eric Rosen  wrote:

>
> Phillip> But I rather suspect that the reason that this is happening is
> that
> Phillip> people know full well that there is a process and choose to ignore
> Phillip> it because they either can't be bothered to put up with the hassle
> Phillip> or don't think that the application will be accepted.
>
> Lars> Suspect all you want, but it doesn't match my experience.
>
> Phillip's suspicion certainly matches my experience over the past 15 years,
> and I've even done my own share of codepoint squatting.  He is also correct
> to state that many folks try to use control over the codepoint space as
> part
> of their competitive marketing strategy.  The only way to avoid collisions
> due to "squatting" is to adopt a policy that all codepoint fields be large
> enough so that a significant number of codepoints are available for FCFS
> allocations.
>


One rather critical consideration here is that the lack of control provides
the IETF with some rather important protection against this type of attack
and is one of the reasons that the loose organizational structures are
relatively stable.

If the registry was a control point there would be far more people
attempting to capture it.





-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: this seems to have become broken some time back

[ned+ietf]

> On 2011-01-18, at 15:03, bill manning wrote:

> > and I guess I am the only one who might still use it - but regardless, if 
> > its broken, it should   seems that the mail attachment (MIME) is no 
> > longer a copy of the draft in question, its a dummy text block.

> I don't think it was ever a copy of the draft in question; it has been an
> RFC1873-compliant Message/External-Body section as long as I have been
> watching. To draw from another random example that came through recently on
> i-d-announce:

> > Content-Type: Message/External-body;
> > name="draft-ietf-idr-bgp-identifier-13.txt"; site="ftp.ietf.org";
> > access-type="anon-ftp"; directory="internet-drafts"

That's an anon-ftp access type, which is described in RFC 2046 section
5.2.3.3. RFC 1873 defines the content-id access-type.

> I've never used a mail client that knows what to do with that, though.

The client I'm using right now (which I coauthored) is one of the very few with
support for external body dereferencing. It's too bad really; it's a very
useful feature, especially if the client does a good job of merging the
external reference into the message.

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