from:"S Moonesamy"


Hi Phillip,
At 15:53 27-08-2013, Phillip Hallam-Baker wrote:
What I found incredibly rude was when an AD and Working Group chair 
actually hissed when I gave my company name at the mic.


I submitted draft-moonesamy-ietf-conduct-3184bis  During the 
discussions (see thread at 
http://www.ietf.org/mail-archive/web/diversity/current/msg00201.html 
)about the draft it was suggested there should be consequences of not 
following the code of conduct.  What action would you suggest against:


 (i)  the Area Director in a case such as the above?

 (ii) the Working Group chair in a case such as the above?

Regards,
S. Moonesamy

Re: Rude responses (sergeant-at-arms?)


At 10:11 27-08-2013, Ted Lemon wrote:
But the most rude behavior that ever occurs on IETF mailing lists is 
not listening.   Not trying to understand what the person who is 
speaking to you has said.   Not trying to figure out if what they 
said meaningfully contradicts your own position, and not making a 
sincere effort to determine if they might be correct in 
contradicting your position.


Yes.

We have seen some incredible rudeness of this type in the recent 
spfbis discussion, with various supposedly smart people in our 
community utterly ignoring what their opponents are saying, and 
simply re-asserting their own position in a variety of ways.


I'll add the message from Scott Brim below and comment.

At 10:20 27-08-2013, Scott Brim wrote:
IMHO that's not a job for the sergeant at arms.  The SAA is 
responsible for how things are said.  The shepherd -- or 
supershepherd or whatever -- would be responsible for the substance.


The shepherd would have to request PR-action on the grounds that 
there has been a BCP violation.  That would cause other process 
issues.  The community will remain quiet and the shepherd will take the fall.


At 12:08 27-08-2013, John Leslie wrote:

   I feel sorry for Ted, who _does_ have to evaluate consensus here.


Me too.

Regards,
S. Moonesamy

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard


Hi Joe,
At 08:59 27-08-2013, Joe Abley wrote:
The consistent word for this in 1035 is simply "message". "DNS 
Message" is in more common use today, I would say.


The text you quoted from 1035 is most usefully interpreted as a 
contraction of "messages sent over UDP"; "UDP message" really 
doesn't have a well-understood meaning, and is easily conflated with 
"UDP datagram" which does not have a size limitation of 512 bytes.


Thanks for explaining this.  Please note that I personally agree with 
what you wrote.


My understanding is that the text in Section 3.4 is trying to say DNS 
messages over UDP.  There was some discussion about that (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03088.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03090.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03109.html ).


Regards,
S. Moonesamy (as document shepherd)

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt


Hi Mary,
At 07:28 27-08-2013, Mary Barnes wrote:
As far as the IPR, as the shepherd and DISPATCH WG co-chair, I 
posted a note to the DISPATCH WG mailing list before progressing 
this document to see if anyone had any concerns about the IPR 
disclosures, which had been discussed in the past and were updated 
when I asked the authors the requisite questions about IPR while 
doing the PROTO write-up.  No concerns were raised with regards to 
the updated IPR disclosures (i.e., no one responded to that 
email). And, you can google  "draft montemurro ietf ipr 
archives" to find past discussions such as this one:  draft 
montemurro ietf ipr archives


Thanks for the feedback.  Somebody commented that:

  "It has nothing to do with IPR which was extensively discussed on
   the dispatch list."

I read the DISPATCH mailing list archives.  I did not see that 
extensive discussion.  My comment was about that.  I do not have any 
problem with the document shepherd comments.


Regards,
S. Moonesamy

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-08-26 Thread S Moonesamy

thing as a UDP packet.




Per RFC1035
Section 2.3.4. Size limits
UDP messages512 octets or less


I'll suggest UDP message.

A reduction to 450 octets would be a reasonable recommendation for 
the DNS _message_, not the UDP _packet_.  The packet still needs to 
carry the IP and UDP headers.


Yes.  I misunderstood your previous arguments.

There should be some type of warning at minimum as the macro issue 
is likely to affect interchange now and going forward.  The IETF 
should not consider protocols outside larger concerns of the well 
being of the Internet infrastructure and proper interchange.  This 
issue should not be controversial.


I'll consider the "macro" issue as addressed.

Regards,
S. Moonesamy (as document shepherd)

Re: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-08-24 Thread S Moonesamy

 about the "ptr" 
mechanism ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00808.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00811.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03184.html ).


There is the following text in the write-up:

   "There was some controversy about whether the use of macros was a
security risk and whether to deprecate the PTR feature.  There was a
formal appeal of the SPFBIS WG chair' interpretation of the charter,
specifically regarding the removal of "unused" features.  The two
features in particular which drove the appeal were the PTR feature
and the local-part macro feature.  These features were not removed
from the document given that the appeal was denied by the Responsible
Area Director."

I hope that the above explains the decision.

The WG should have been told to focus on security and at better 
insuring interchange to achieve a safer stance moving forward.


The working group was reminded about BCP 72.

Regards,
S. Moonesamy (as document shepherd)

Re: The Last Call social contract (was - Re: Rude responses)

2013-08-23 Thread S Moonesamy


Hi Dave,

I read the messages on this thread.  I suggested to the participant 
to comment.  I am okay with the comments which were made.  I had an 
off-list exchange before the message that generated the other 
thread.  The exchange was not antagonistic.


Some people read "please read the archives" as a requirement.  That 
led to a misunderstanding.  During a Last Call someone has to figure 
out what the issues are and whether they have been addressed or 
not.  The misunderstandings do not make the work easier.


Regards,
S. Moonesamy

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-08-23 Thread S Moonesamy


Hello,

This message has a Bcc to an IETF participant.

In my write-up for the Responsible Area Director I mentioned that:

  "There was an intermediate conclusion about the topic of whether the SPF
   protocol should use the SPF RRTYPE or the TXT resource record.  It was
   followed by an objection.  After discussion of the topic at the IETF 83
   SPFBIS WG session the conclusion reached was that the decision would be
   not to publish RRTYPE 99 and and not to query RRTYPE 99.  The WG
   consensus about the RRTYPE can be described as particularly rough.  The
   topic of obsoleting the SPF RRTYPE generated a lot of controversy near
   the end of the WGLC.  There were a very high number of messages about
   the topic on the SPFBIS mailing list and the DNSEXT mailing list as some
   DNSEXT WG participants were not aware of RFC 6686."

The WGLC announcement [1] for draft-ietf-spfbis-4408bis-14 was sent 
on April 9, 2013 and it was mentioned that the WGLC will close on 
April 24.  I posted my review as document shepherd on April 23 [2] 
and looked into the IANA Considerations Section of the draft as there 
is a question in the write-up about whether the IANA Considerations 
are clear and complete.  Something unusual occurred.  A very high 
number of messages were posted about on a thread about the DNS 
Parameters registry [3].  Most of the comments were submitted after 
the end of the WGLC.  On April 25, the Responsible Area Director [4] 
commented that:


  "This discussion should have happened at SPFBIS *chartering* time, as it is
   crystal clear from the charter that existing features currently 
in use in SPF
   are not going away. Indeed, the TXT record was specifically 
mentioned in the

   charter."

In another message he commented [5] that:

 "If you think SPFBIS was being superficial in its treatment of this topic
  and can identify an argument that was missed, fine."

The thread was left to run in case an argument was missed.  The 
SPFBIS WG Chairs [6] posted a message on April 30 about "the planned 
deprecation of the SPF RRTYPE and whether TXT is an appropriate thing 
to use and if it is whether the SPF use of it is ok".


There is the following text in the write-up:

 "Some WG participants have mentioned that they may express extreme
  discontent about the decision to obsolete the SPF RRTYPE during
  the Last Call."

That is a notification to the Responsible Area Director and the other 
members of the IESG about the matter.


I reviewed the discussion about the RRTYPE several times in doing the 
write-up and after that to determine whether the following is correct:


  "The WG consensus about the RRTYPE can be described as particularly rough."

I did not find any problem in the process followed to reach that 
conclusion.  I read the messages posted on the IETF mailing list [7]; 
there are around a 100 messages.  I didn't notice any messages about 
an issue with the above statement.


Regards,
S. Moonesamy (as document shepherd)

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03497.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg03507.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg03681.html
7. http://www.ietf.org/mail-archive/web/ietf/current/msg81609.html

Re: SPFBIS LAST CALL: SenderID Framework (PRA, SUBMITTER)

2013-08-22 Thread S Moonesamy


Hi Hector,
At 07:29 22-08-2013, Hector Santos wrote:
Besides the SPF type issue, I believe there are still a number of 
integrated protocol issues to address.  How does the following RFCs 
play into SPFBIS output, the SPF type and the overall BIS document? 
Should RFC4408BIS update any of these documents?


[1] RFC4405  SUBMITTER SMTP Service Extension
[2] RFC4406  Sender ID: Authenticating E-Mail
[3] RFC4407  Purported Responsible Address (PRA)


I would say no as the above RFCs are not related to 
draft-ietf-spfbis-4408bis-19.  I'll mention the following text from RFC 6686:


  "The experiments comprising the series of RFCs defining the
   SUBMITTER SMTP extension (RFC4405), the Sender ID mechanism
   (RFC4406), the Purported Responsible Address algorithm (RFC4407),
and SPF (RFC4408), should be considered concluded.

That is the official position of the IETF.  I can state that the text 
reflects the consensus of the SPFBIS WG as I verified whether there 
was working group agreement before requesting the publication of RFC 
6686.  The following text is from RFC 6686:


  "This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG)."

From an IETF perspective that's the answer that will be given.


For example:

In RFC 4406 (SenderID), section 3.1 says:

   This section replaces the definition of the version identifier in
   Section 4.5 of [RFC4408] and adds the concept of SPF record scopes.

In section 4.4, item 1:

   1. If any records of type SPF are in the set, then all records of
  type TXT are discarded.

Overall,

1) Do SenderID publishers need to drop the SPF type as well?

2) Do PRA/SUBMITTER compliant receivers need to also drop SPF type queries?

3) Do SMTP vendors need to begin dropping SUBMITTER as well?


Somebody can submit a draft which answers those questions and have it 
discussed in the IETF.  The SPFBIS WG Chairs have mentioned that once 
the work on draft-ietf-spfbis-4408bis is completed the SPFBIS WG will 
be ready to close ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10124.html 
).  I don't think that the SPFBIS WG will take on the draft.  The 
person submitting the draft can contact the Application Area 
Directors to find out where to discuss the draft.


Procedurally, does SPFBIS need to address or take over these 
multiple protocols integration concerns (including SMTP SUBMITTER 
receivers) or should it just remain silent and allow vendors make a 
guess at all this?  What is the SPF summary in this regard for the 
application integrator?


Procedurally, the SPFBIS WG does not need to address that (see above 
comments).  SPFBIS will remain silent and allow vendors to make a 
guess.  The SPF summary is that it is out of scope for 
draft-ietf-spfbis-4408bis-19.


Should the IETF consider a new SenderID WG to discuss what are the 
repercussions the SPFBIS results have on it?


The above question is about a SenderID BoF.  I personally do not 
think that there is currently interest in having that BoF (see RFC 5434).


Regards,
S. Moonesamy

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard


Hi John,
At 20:02 21-08-2013, John Leslie wrote:

   If this is the sort of response given to somewhat-valid questions
raised about the draft being proposed, Pete will eventually have to
say there _is_ no consensus. :^(


An Area Director may say that. :-(

Regards,
S. Moonesamy

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard


Hi Eliot,
At 03:26 21-08-2013, Eliot Lear wrote:
First, I appreciate that you and Dave are bringing data to the 
table.  However, in this case, it is not in dispute that queries are 
happening.  What *is* in dispute is whether there are answers.  I 
must admit I am having a difficult time understanding the logic, 
even so.  The *hard* part about this was supposed to be 
implementation of the record in the application software.  Can the 
shepherd answer this question:

To what extent has that happened?


There is a thread about libspf2 querying for RRTYPE 99 first ( 
https://lists.exim.org/lurker/message/20110812.094310.3a53c0f6.gl.html#exim-users 
).


I'll also mention 
http://support.godaddy.com/groups/domains-management-and-services/forum/topic/spf-type-99/ 
and http://features.cpanel.net/responses/ability-to-create-spf-type-99-records


Here are a few messages on the SPFBIS mailing list about RRTYPE 99:

http://www.ietf.org/mail-archive/web/spfbis/current/msg00555.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg03778.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg03781.html

The SPFBIS WG Chair asked a question about what to conclude given the 
SPFBIS Charter ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03779.html ).


Regards,
S. Moonesamy (as document shepherd)

Re: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)


Hello,

Lars Eggert mentioned [1] the following:

  "cool off, take the intensity out of the discussion, and try
   to provide data/facts for your different standpoints, so the
   rest of us who are sitting on the sidelines watching the
   fireworks can form an opinion."

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/diversity/current/msg00222.html

Re: Last call of draft-ietf-spfbis-4408bis-19

Hi Patrik,
At 11:58 20-08-2013, Patrik Fältström wrote:
As the bottle is opened, I hereby state my
objection to Section 3.1 of
draft-ietf-spfbis-4408bis-19 for the reasons
explained below. I do agree (as stated below)
that the section of RFC 4408 that specify how to
use both SPF and TXT resource record types
include an error as it does not lead to interoperability.

As the intention with use of both TXT and SPF
originally was to migrate from TXT to SPF I
instead of what is outlined in the draft suggest
that a proper migration strategy is laid out
(look up mandatory to implement SPF and fall
back to TXT). This instead of deprecation of the SPF record.

In general I do believe, for example when
looking at IPv6 and DNSSEC and similar
technologies, that the lifetime of RFC 4408 is
too short to deprecate any of the proposed
records that are in use, specifically as RFC
4408 explicitly do allow use of both.

draft-ietf-spfbis-4408bis-19 is not the usual
Proposed Standard effort. The SPFBIS WG was
tasked to move RFC 4408 to Proposed Standard with
restrictions. One of the restrictions is not to
review the design. I hope that explains why
draft-ietf-spfbis-4408bis-19 is what it is. I
suggested to the working group to review the
issue of the migration strategy (see
http://www.ietf.org/mail-archive/web/spfbis/current/msg03934.html ).

From Section 3.1.1 of RFC 4408:

"It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose."

There isn't similar text
in draft-ietf-spfbis-4408bis-19. Hector Santos commented that:

"we will add SPF type support in our implementation once the infrastructure
is ready. For us, as a windows shop, namely Microsoft DNS servers."

I read
http://social.technet.microsoft.com/Forums/windowsserver/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records
My conclusion is that there is a DNS server that cannot handle the new RR Type.

The question is how to address the objection about the migration strategy.

Regards,
S. Moonesamy (as document shepherd)

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard


At 04:55 21-08-2013, manning bill wrote:
regarding adoption  it would be interesting to 
take a second snapshot from each of these servers in about six months
to see if the trend has changed (modulo PAFs 
observations that not all TXT == SPF).   In the 
mean time, declare a suspension of
last call to gauge if the presumption of failure 
of the SPF RR merits this drastic action.


The IETF chartered the SPFBIS WG to deliver:

  (i)   A document describing the SPF/Sender-ID experiment and its
conclusions to the IESG for publication.

  (ii)  A standards track document defining SPF, based on RFC4408
and as amended above, to the IESG for publication.

There is a message from the Responsible Area 
Director ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html 
) and the SPFBIS Chairs ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html 
) about (i).  The SPFBIS  WG was asked to make a 
good-faith effort and that is what the working group did.


The editor of RFC 6686 did a good job.  The IESG 
approved the publication of the draft.  The 
working group worked on its second deliverable 
(ii) after that.  There wasn't any concern about 
the TXT RR as the matter was considered as 
resolved in RFC 6686.  I asked DNSEXT about the 
SPF RRTYPE in the (IANA) DNS Parameters registry 
( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html 
).  It generated long threads on several IETF 
mailing lists.  It was unusual to have that 
amount of comments after the end of a WGLC.


Suspending the Last Call for six months is a 
drastic action.  I would ask the Responsible Area 
Director to consider that if the SPFBIS WG did 
not make a good-faith effort or if there is an 
issue with the process that was followed.  My 
opinion is that the SPFBIS WG made a good-faith 
effort.  There are at least three Area Directors 
reading the SPFBIS mailing list.  They did not flag any process-related issue.


At 07:03 21-08-2013, Jelte Jansen wrote:

Just wondering, could OARC's recent DITL data help? (perhaps if only to
see whether another large-scale targeted effort is needed)


Yes.  Someone also has to do the work.

Regards,
S. Moonesamy (as document shepherd)

Re: [dnsext] Deprecating SPF


Hi Patrik,
At 11:45 20-08-2013, Patrik Fältström wrote:
The reason why I did not post there at first was 
that a) I did not feel I had followed the rules 
laid out for discussions [read all messages in 
the mailing list archives] and b) the discussion 
on the dnsext list was more general on overload 
of TXT records [something DNS people have always 
been against -- see IAB document on DNS choices].


But, when having that discussion on the dnsext 
mailing list, to which I cc:ed Pete as 
responsible AD for full disclosure, Pete did ask 
me for a complete explanation of my view, which I posted.


Once again, without re-reading the mailing list archives.


First of all, I apologize for copying the message 
to ietf@.  The advice given was to read the 
comments in the SPFBIS mailing list archives.  It 
is not a rule.  If a person did not read all the 
messages and the person raises a point or 
provides arguments which were not discussed 
previously I will ask the SPFBIS WG to address them.


I don't know whether to process your comments or 
the other comments posted on dnsext@ as part of 
the Last Call or not.  It is unclear to me as to 
whether I should only consider messages with the 
appropriate Last Call subject line.  My sense is 
that I should listen to your concerns.


Regards,
S. Moonesamy

Re: [dnsext] Deprecating SPF


Hi Patrik,

I am copying the message to ieft@ as there is an ongoing Last Call.

At 08:28 20-08-2013, Patrik Fältström wrote:
The consensus related to how to fix RFC 4408 
will be very rough. That is clear. And I feel 
sorry for responsible AD and IESG to be forced 
to make a decision that such a large rough part 
of the rough consensus will not be happy with. 
Regardless of what the decision will be.



An architectural correct solution is to change:

OLD:

   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.  A compliant domain name MUST have a record of at least one
   type.  If a domain has records of both types, they MUST have
   identical content.

NEW:

   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.  A compliant domain name MUST have a record of at type SPF,
   code 99.  Lookup MUST first be of type SPF and SHOULD if no response
   is received be of type TXT.


Reasoning: The use of the TXT record for SPF is 
not sounds for a number of reasons:


1. The TXT record already can have multiple 
fields, and it is very unfortunate that the SPF 
use of TXT records do not use that feature. 
Instead the SPF specification do say that the 
first field should be used, and if there are 
more than one they should be concatenated. After 
one have one and only one field, that field 
should be parsed and divided in fields.


2. It is even (compared to some other TXT 
related documents) pointed out in RFC 4408 that 
collisions as described in RFC 5507 might happen.


3. It is also pointed out that there might be 
size issues with the records, and experience 
from use of NAPTR show that selecting a 
preferred mechanism that potentially blows the 
size of the RRSet is not very wise. This is btw 
why the URI RR Type do not use a prefixed length 
"text" field in the RDATA but do set the string 
the URI is to the full length of the RDATA, i.e. 
without any 255 byte limitation.


4. DNS is by design (as pointed out in RFC 5507) 
created with a tuple consisting of owner, type 
and class for selection by the client what 
record set to be retrieved. This RRSet 
architecture is something that comes back not 
only in the query/response architecture of the 
DNS protocol, but also in the DNSSEC 
architecture where RRSets are the units that are 
signed. Not explicitly ensuring an RRSet is used 
for SPF (and nothing more) is an architectural choice I strongly am against.



Because of these reasons, I do believe the 
choice is wrong to say that TXT MUST be 
implemented and instead I am in favor of having 
type SPF be mandatory for interoperability with fallback to lookup of TXT.


From Section 3.1 of draft-ietf-spfbis-4408bis-19:

  "SPF records MUST be published as a DNS TXT (type 16) Resource Record
   (RR) [RFC1035] only.  The character content of the record is encoded
   as [US-ASCII].  Use of alternative DNS RR types was supported in
   SPF's experimental phase, but has been discontinued."

There is a message from Pete Resnick about RFC 
2119 usage ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html 
).  The interpretation of "SHOULD" and MUST" in 
that part of RFC 4408 was an issue which the SPFBIS WG discussed about.


It would be better to have the discussion on the 
ietf@ mailing list as that's the venue which the 
IESG identified for last Call comments.


Regards,
S. Moonesamy

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard


Hi Hector,
At 07:16 20-08-2013, Hector Santos wrote:
This doesn't seem to be correct. My apology if I don't follow or see 
the logic.   The only real issue as it was since day zero in MARID 
was the infrastructure support for recursive passthru queries which 
is what RFC 3597 (Handling of Unknown DNS Resource Record (RR) 
Type).  Without this, which allows for servers to delay/plan direct 
new RR type support yet still not error out on an unnamed type, 
there COULD NOT be any reasonable expectation to even only suggest a 
dual query migration approach, either in serial or parallel. It is 
very important to consider the mindset when it was first considered 
and written for RFC 4408 because to me, that is the mindset that has changed.


This would be a process issue then as the SPFBIS Chairs determination 
was made on the basic of the text from the SPFBIS Charter which was 
cited.  A person can raise an objection (I am okay with that as 
that's part of the work) with substantive comments to support the objection.


I hope I am reading this incorrectly.  It may be too procedural 
oriented to me at this point.


I would like to see a simple just distinctive consensus on what the 
entire IETF/DNS community believes is the future of DNS servers 
offering unnamed RR type processing because that is the main barrier 
for any kind success. We knew this as far back as MARID.  I don't 
quite understand why this key point seems to be left out, instead 
MARID was deemed off topic. That was an error because if there is no 
future in unnamed RR type support, then it really doesn't matter and 
the problem is solved. TXT only will be the only fast entry point 
for new DNS DOMAIN policy applications.


If the community still believes it possible, then clarifying and 
codifying the SPF/TYPE lookup procedure seems to me to be the only 
real correction to make here.


My reading of  the SPFBIS Charter is that the working group was not 
tasked to work on the future of DNS servers.  That does not mean that 
arguments about the future of DNS servers are not relevant.


There are several questions:

 (a) Was there an error in RFC 4408?

 (b) What was the error in RFC 4408?

 (c) Why was there an error in RFC 4408?

 (d) What should be done about the error?

There isn't anything that can be done about question (c) except not 
to repeat the same mistake.


Is there disagreement on the answers to questions (a) and (b)?

Regards,
S. Moonesamy (as document shepherd)

Re: [spfbis] SPF TYPE support

mments about RFC 3567 during the working group 
discussions (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00545.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00820.html ).


If this is no longer the expectation, then it would make sense to 
remove the SPF type but also be aware that in general, this will 
also  nix (not help) any future idea for successfully adopting new RR types.
It would be added statement that TXT based applications are 
acceptable.  I think the DNS community continues to have a problem with this.


Noted.

SM, Pete, thank you for the opportunity to clarify my point. For the 
record, there was no intent to imply it occurred but quite frankly 
when it is repeatedly stated, this deeply divided issue has not be 
resolved at any point,  it does have an intimidation factor.  As Mr. 
Crocker stated, the burden is on the those who oppose the removal. 
But my question was always why was the decision made to remove in 
the first place done when in fact it was quite obvious it would not 
have industry wide endorsement. The burden should of been to justify 
removal. Now it has become difficult to effectively add it back. 
This is why I posed the question in two forums to get community 
input over the last few years. It was quite obvious to me that the 
DNS community would be against this removal.  So in this vain, it 
was prematurely removed in the WG without early IETF/IESG/DNS 
concerns adequately dealt with.  Unfortunately, we were advise to 
raise the issue again in LC, but by that point, all the IETF 
procedural moves were made making it it a very high burden to add 
something that should not been removed in the first place.


There are two SPFBIS WG Chairs.  The way we work is: I read the 
mailing list messages, the other Chair reads the mailing list 
messages, each chair reaches his own conclusion and we discuss about 
it.  Once the Chairs agree a message is posted to the WG mailing 
list.  Let's assume that the Chairs did not carefully consider the 
comments or their determination was incorrect.  There is a Last Call 
where the matter can be raised again.  That is the advice that was 
given.  There is indeed a high burden as the person raising the issue 
again will have to read the mailing list messages to determine 
whether they have been carefully considered.


Regards,
S. Moonesamy (as document shepherd)

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-08-19 Thread S Moonesamy


At 08:05 19-08-2013, MÃns Nilsson wrote:

I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as
RFC unless substantial parts are reworked.

* The charter disallows major protocol changes -- removing the SPF RR type
is a direct charter violation; since SPF is being used on the Internet.

* The overloading of the TXT record is a hack at best, aimed at
circumventing DNS management systems vendors that fail to ship
support. Breaking the DNS model with specific resource records is not
the way to get better application support. (besides, the major argument
at the time was "it's so hard and takes ages to get a RR type", which
isn't true anymore and also, the RRtype is allocated, what's the fuss? )

* The empirical data that was gathered and the conclusions from which
that where published as RFC 6686 are IMNSHO flawed and rushed in that they
set far too optimistic deadlines for adaptation before declaring failure.

The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and tell
the wg that instead of deprecating SPF it should be algorithmically
preferred while maintaining support for TXT.


I read the SPFBIS charter ( 
https://datatracker.ietf.org/wg/spfbis/charter/ ) 
again.  The charter violation the above may be referring might be about:


 "Specifically out-of-scope for this working group:

  * Removal of existing features that are in current use."

There is a message from the Responsible Area 
Director at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html 
which might shine some light about that part of the charter.


Both RR Type 16 and RR Type 99 are in use on the 
Internet.  Tony Hansen mentioned during the IETF 83 session that:


  "when you write a protocol, there is definite harm if there is a
   choice in what you publish and what you look for.  He is of
   the view that there is a definite bug in RFC 4408."

Fixing that bug falls within the scope of the SPFBIS charter, specifically:

  "Changes to the SPF specification will be limited to the correction
   of errors, removal of unused features, addition of any enhancements
   that have already gained widespread support, and addition of
   clarifying language. "

The fourth paragraph (see quoted text) states 
that the conclusions from that where RFC 6866 
were flawed and rushed.  The explanation given is 
because the working group declared failure too 
soon.  The SPFBIS WG discovered a bug during the 
review of the SPF specification.  One of the main 
considerations for the decision was to fix the 
bug.  The working group had to choose one RRTYPE 
as the conclusion was that it was the appropriate 
way to fix the bug and ensure interoperability.


The comments posted up to now for the Last Call 
points to a disagreement about the choice of RRTYPE.


Regards,
S. Moonesamy (as document shepherd)

Re: SPF TYPE support

2013-08-19 Thread S Moonesamy


Hi Hector,
At 14:10 19-08-2013, Hector Santos wrote:
I'm having a hard time with both sides of the argument, especially 
the supposed existence of an "interop problem" which seems to only 
highlight how to "procedurally" stump the SPF type advocates with a 
"error correction" standpoint.   What is that error by the way?


In a message dated February 27, 2012, the SPFBIS Chairs commented 
that the discussion about Issue #9 (SPF RRTYPE) has revealed an 
interoperability concern in the existing RFC (4408).


From RFC 6686:

  "RFC 4408 itself included a faulty transition plan, likely because of
   the late addition of a requirement to develop one -- it said:

  An SPF-compliant domain name SHOULD have SPF records of both RR
  types.  A compliant domain name MUST have a record of at least
  one type.

   which means both can claim to be fully compliant while failing
   utterly to interoperate."

The consensus of the SPFBIS WG was that this is an interoperability 
issue and it would have to be corrected.  That is what was considered 
as an error correction.


I don't believe there was an adequate answer from the advocates of 
removing the SPF RR type and the repeated assertion that its been 
discussed at length has not been convincing it was appropriately 
addressed. It all seem to be a "Shut up" approach to the problem 
(always suggest that its been discussed already). This seems to be 
one of the reasons why the issue will not go away.


I personally do not think that it is appropriate to ask any working 
group participant to "shut up".  I welcome hearing arguments and I 
expect a working group to carefully consider them.


Regards,
S. Moonesamy (as document shepherd)

Re: Last Call: (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard

2013-08-13 Thread S Moonesamy


At 15:14 12-08-2013, Graham Klyne wrote:
But, in a personal capacity, not as designated reviewer, I have to 
ask *why* this needs to be a URI.  As far as I can tell, it is 
intended for use only in very constrained environments, where there 
seems to be little value in having an identifier that can appear in 
all the contexts where a URI may be recognized.


This is an individual comment.  I reviewed 
draft-petithuguenin-behave-turn-uris-05.  I wondered why a URI was 
needed given the limited use.  The same argument is applicable for 
draft-nandakumar-rtcweb-stun-uri-05.  There is running code for both 
drafts.  Both draft qualify for "DNP".  I would describe the 
proposals as trying to fit the solution within a URI instead of 
designing a URI scheme.  Both proposals sound like UNSAF.


Regards,
S. Moonesamy

Re: Data collection for remote participation

2013-08-13 Thread S Moonesamy


Hi Vinayak,
At 06:09 AM 8/12/2013, Vinayak Hegde wrote:

There has been a lot of discussion on the IETF mailing list regarding
improving remote participation and improving diversity on the mailing
lists and in the working groups. I think the two are related. I think
everyone broadly agrees that remote participation can be better. If
nothing else, it will tell about who the remote participants are. I
had proposed a few steps in this direction by improving the data
collection for remote participation in the IAOC Sunday meeting.
Posting them below again for discussion on the mailing lists.

It can be a simple form that asks the following questions (Can be
refined - this is just a start)
1. Name:
2. Country:
3. Duration of participation in IETF (either in number of years or
number of meetings)
4. Employer ?
5. Working groups interested in.

This can be voluntary and can be done pre-IETF meeting. As of now
there is no structured way to know how many people wre active in the
jabber room or listening on the audio stream.


As the data collection is voluntary it should not be a problem to ask 
for the information mentioned above.



I can see that this has multiple benefits.
1. If the number of participants in a certain WG is more, it would
push the WG chair to request for the slides/agenda available earlier.


I suggest asking the working group for the agenda if it is not available.


2. If there are consistently more participation from around the world,
the the WG chair can request for a meetecho recording so people can
follow the group even if they cannot attend the meeting live. This
could be useful for people who have clashing schedules as well.


Yes.


3. Over a longer period of time, it can help IETF plan and encourage
remote participation. Currently there is no hard data on number of
remote participants. There is however a lot of hand waving so this
will get some useful data into the system.


There is the usual hand waving. :-)  It is a good start.  The 
information available over a period of time might provide a view of 
whether there is any improvement in remote participation.


At 08:56 AM 8/12/2013, Vinayak Hegde wrote:

This was a suggestion but I don't think it will work well. OTOH an
argument can be made that money gathered from charging remote
participants can be used to fund better tools for remote
participation.


After reading about the remote participation issues which have been 
discussed on this mailing list I don't think that the problem is the tools.


Regards,
S. Moonesamy

The Friday Report

2013-08-04 Thread S Moonesamy


Hi Abdussalam,

The IETF Chair used "AB" as your name in his report during the 
plenary.  I assume that it is okay for me to call you 
"Abdussalam".  I should have used "Mr Baryun" as that is how it is 
done in some cultures.


Somebody (outside the IETF) wrote that, in general, those living in 
richer countries appear to treat one another less kindly than their 
counterparts in poorer nations.  In my personal opinion bullying is 
not okay.  If you are of the opinion that you are being bullied 
please feel free to email me if you would like to talk to me about it.


Regards,
S. Moonesamy

Re: Last Call: (Using the International Mobile station Equipment Identity(IMEI)URN as an Instance ID) to Informational RFC

2013-07-22 Thread S Moonesamy


At 07:35 19-07-2013, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'Using the International Mobile station Equipment Identity(IMEI)URN as
   an Instance ID'
   as Informational
RFC

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 2013-08-16. Exceptionally, comments may be


Section 4 describes the 3GPP use case as:

  "The mobile device includes its IMEI in the SIP REGISTER request
   so that the registrar can perform a check of the Equipment Identity
   Register (EIR) to verify if this mobile device is allowed or barred
   from accessing the network for non-emergency services"

The draft then argues that non-REGISTER requests except in case of an 
emergency.


In Section 5:

  'A UAC MUST NOT include the "sip.instance" media feature tag
   containing the GSMA IMEI URN in the Contact header field of non-
   REGISTER requests except when the request is related to an emergency
   session.  Regulatory requirements can require the IMEI to be provided
   to the Public Safety Answering Point (PSAP).  Any future exceptions
   to this prohibition require a RFC that addresses how privacy is not
   violated by such a usage.'

My reading of the above is there is a privacy violation but that 
violation is considered acceptable in the use case mentioned 
above.  Any other use case requires a RFC to be published.  There is 
an additional requirement; the RFC has to address how privacy is not 
violated.  It is an unusual requirement in a RFC.


From Section 9:

  'In particular, the "sip.instance" media feature tag containing the
   GSMA IMEI URN MUST NOT be included in requests or responses intended
   to convey any level of anonymity.'

The above can be interpreted in various ways.  The problem might be 
that the draft builds upon RFC 5626 which states that "some other 
privacy concern requires that the UA not reveal its identity".  It 
may be better to state that there is a violation of privacy.


The draft does not discuss about the weakness of the mechanism or how 
what it proposes can be used for wiretapping.


Regards,
S. Moonesamy

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

2013-07-21 Thread S Moonesamy


At 00:03 21-07-2013, Andrew Allen wrote:
The reason why the IMEI namespace is being registered as a GSMA 
namespace and not as part of the 3GPP namespace is that the GSMA has 
the responsibility for IMEI assignment and hence in maintaining 
uniqueness of the namespace. It has nothing to do with IPR which was 
extensively discussed on the dispatch list.


I read the dispatch mailing list.  I did not see the extensive 
discussion.  I saw the following comment "Surely that is just trying 
to turn the IETF into the policeman".


The primary purpose of the IMEI is for preventing use of stolen 
mobile phones and enabling emergency calls to be made from mobiles 
that don't have a valid subscription.


From what I read the main purpose of the IMEI is to be able to take 
measures against stolen phones and against equipment which the use 
cannot be accepted for technical or safety reasons.  The secondary 
purpose is the tracing of malicious calls.


There is an apps which sends the IMEI in a 
cryptographically-protected form over the network.  For what it is 
worth, it's MD5.


There has been some work in the IETF on emergency calls (see service URN).

At 00:12 21-07-2013, Andrew Allen wrote:
As John pointed out having the sub namespace reviewed by IETF 
provides the opportunity to add text to address privacy concerns 
with any inappropriate usage.


I don't think that it is the role of the IETF to determine whether 
the usage of a sub-namespace is appropriate or not as it can cause 
namespace management issues.


I tried the explain the subtlety between privacy concerns and privacy 
considerations.  The IMEI can also be used as a customer identifier.


Regards,
S. Moonesamy

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

2013-07-20 Thread S Moonesamy


Hi John,
At 18:23 20-07-2013, John C Klensin wrote:

See my earlier note, but mostly to aid in getting the
documentation right.  For example, to the extent that the recent
discussion results in a more complete treatment of privacy
and/or security considerations in the documentation, that is a
net improvement and added value.


There was a Last Call for draft-montemurro-gsma-imei-urn-01 in 
2007.  The draft was sponsored by an Apps 
AD.  draft-montemurro-gsma-imei-urn-04 was evaluated (I did not 
verify the details) in 2009.  An IPR disclosure, about a patent filed 
several years ago, was filed after that evaluation.  The DISCUSS got 
cleared automatically.  draft-montemurro-gsma-imei-urn-08  was 
dispatched to RAI in 2011.


3GPP was assigned a URN in 2008.  The shepherd write-up 
for  draft-montemurro-gsma-imei-urn-16 mentions that "this document 
is required for the 3GPP/IMS specification, thus any
vendor that implements the 3GPP specifications follows this 
specification".  The significant difference between the 3GPP URN and 
the requested GSMA URN is that there is an IPR disclosure on that latter.


One of the questions asked by Tim Bray was about the WiFi-only 
scenario.  That was raised previously through a DISCUSS as the softphone issue.


The privacy discussion might cause some discontent.  As for whether 
the draft will gain consensus, well, what can I say; if it is the 
consensus of the IETF to support state-sponsored surveillance there 
is nothing I can do about it. :-)


Regards,
S. Moonesamy

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

2013-07-20 Thread S Moonesamy


Hi Andrew,
At 13:48 20-07-2013, Andrew Allen wrote:

I think IANA registration of namespaces has a lot of value.


draft-montemurro-gsma-imei-urn-16 discusses about two namespaces:

 (i)  gsma

 (ii) imei

It is not possible to get a IANA registration for (ii) as according 
to draft-montemurro-gsma-imei-urn-16 (ii) is managed by (i).  In 
simple terms (ii) does not require IETF approval.


Regards,
S. Moonesamy

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

2013-07-20 Thread S Moonesamy


At 15:53 19-07-2013, Andrew Allen wrote:

Do you not think that the text in the security considerations section::

"because IMEIs can be loosely correlated to a user, they need to be 
treated as any other personally identifiable information. In 
particular, the IMEI URN MUST NOT be included in messages intended 
to convey any level of anonymity"


covers the privacy issue?

If not what is the additional privacy concern?


There is a difference between privacy concerns and privacy 
considerations.  It has been mentioned that "the view in 3GPP was 
that the IMEI should not be of any greater concern when used as an 
instance ID than using a UUID".  draft-montemurro-gsma-imei-urn-16 states that:


  "Specifically the IMEI is to be incorporated in a module which is
   contained within the terminal.  The IMEI SHALL NOT be changed
   after the terminal's production process.  It SHALL resist tampering,
   i.e. manipulation and change, by any means  (e.g. physical,
   electrical and software)."

The pervasive use of UUID in computing does not make it a good 
idea.  I doubt that there has been any privacy analysis of how UUID 
will be used or misused prior to the publication of the RFC.  The 
IMEI is built into the device.  The scope for misuse would be clear 
enough for a person designing identifiers.


From draft-montemurro-gsma-imei-urn-16:

  "Therefore the IMEISV (that is, the IMEI URN with svn parameter)
   MUST NOT be delivered to devices that are not trusted.  Further,
   because IMEIs can be loosely correlated to a user, they need to
   be treated as any other personally identifiable information.  In
   particular, the IMEI URN MUST NOT be included in messages intended
   to convey any level of anonymity."

The IMEI is considered as personal data in some jurisdictions.  There 
is a strong correlation between the IMEI and a user.


I read draft-montemurro-gsma-imei-urn-16 and I see that the four 
authors have listed their phone numbers as "unlisted".  Is there a 
reason for that?  The question may sound unrelated to the draft and 
it can be argued that it is unrelated to the draft.  I asked it as it 
may help the casual reader understand what privacy is 
about.  draft-moonesamy-privacy-identifiers-00 (expired) argues that 
there is an implicit assumption that the underlying protocols are 
transmitting the right amount of information needed for the protocols 
to work.  Is for example, urn:gsma:imei:90420156-025763-0, required 
for SIP to work?  I do not think so.


The world was somewhat naive about privacy in 2006.  Privacy is a hot 
topic nowadays.  The metadata debacle is one of the contributing 
factors.  There seems to be an assumption that the IMEISV is usually 
sent over trusted channels to trusted parties.


The second sentence containing "must not" written in capital letters 
takes a position where anonymity of messages is opt-in.  The GSM 
Association has published a set of principles which mentions "privacy 
by design".  It is up to the reader to read the two sentences quoted 
above and determine whether "privacy by design" is just another 
buzzword or a principle which the GSM Association considers as important.


At 04:23 20-07-2013, Scott Brim wrote:

Thanks, SM, for finding what I said back in 2010.  I still think this
is architected wrong, conflating devices with communication endpoints
higher up the stack, and steers us toward a path toward eventually
"needing" to reduce privacy even more.  However, 3GPP has apparently
already already started marching down that path.  Could our liaison
explain the situation there?  Is anyone actually going to use it?  Is
this a done deal - do we have to support it because otherwise 3 years
of 3GPP work get undone?


As a responding to Scott's comment about the three years of work I 
would say that this has the signs of an inevitable decision.  I'll 
describe the IETF angle as follows:


  Is it okay to assign a Uniform Resource Name namespace for GSMA?

The namespace assignment is not a problem.  Have an assignment 
request sitting in the IETF queue for seven years is a problem.  It 
would be good if someone explained why this happened unless the IETF 
considers it as acceptable to be asked to take inevitable decisions.


I agree with Scott's comment.  Tim Bray already pointed out that this 
is a bad idea.


At 04:53 20-07-2013, GARBA KORA TAMSIRD BELLO wrote:

Yes it true , but more argumentations are welcome


The duck won't fly. :-)

Regards,
S. Moonesamy

Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

2013-07-19 Thread S Moonesamy


At 08:02 19-07-2013, Tim Bray wrote:
I'm not sure from reading the draft what the goal of having this URN 
namespace is, but if it involves encouraging its use by application 
developers, I'm pretty sure it's a bad idea.


I agree that it sounds like a bad idea to encourage application 
developers to use this URN namespace.  There was a documented 
vulnerability which demonstrated how the IMEI could be captured.


In 2006 Leslie Daigle mentioned that the sub-NID namespace does not 
belong in the version of the draft which was reviewed.


I'll quote some comments posted by Scott Brim in September 2010 to 
Apps Area Review.


  'First, this feels like a layering mixup.  When would -- or should -- a
   communicating peer outside a mobile network need to know the IMEI or
   IMEISV of a device inside a mobile network?  An IMEI is used for initial
   identification on a mobile network or for SIM-less emergency calls.
   Under what conditions would an Internet-based peer have an IMEI in hand
   and want to use it in a gsma: URN?  If as you say an "Internet device"
   is "interoperating" with a mobile device, it will do so using IP-based
   protocols and will (should) never learn the mobile device's IMEI.  I can
   see cases where an outsourced management entity might want to speak to a
   mobile network's administration regarding records for a particular IMEI,
   but it would do so in a very secure way, not using this particular URN.'

   If there is an assumption that we are going to start passing around
   IMEIs as general identifiers, then I'm concerned that you are
   engineering a world in which one must reveal permanent identifiers in
   order to communicate.

   Please enlighten me as to the intent.  Right now it feels to me like it
   enables us to do the wrong thing with IMEIs.'

The http://gsmworld.com/newsroom/document%2Dlibrary/ normative 
reference is a 404.


It would be easier to have the draft discuss the GSMA URN only.  The 
alternative is to have the draft discuss the privacy considerations 
of using IMEI and IMEISV.


Regards,
S. Moonesamy

Re: The case of dotless domains

2013-07-16 Thread S Moonesamy


Hi Doug,
At 22:38 15-07-2013, Doug Barton wrote:
Interesting, but pardon my being blunt, it does not seem to cover 
any new ground. You did say one useful thing:


IETF specifications usually provide guidance to ensure 
interoperability.  Whether dotless domains are harmful or not is a 
policy matter.


It's a -00 draft.  The above paragraph is one of the two arguments in 
the draft.


Can you (or Ofer) define how you're using the terms "explicit" and 
"implicit" in terms of DNS search, and what their relevance is to 
the topic of dotless domains? And no, I'm not being snarky, I think 
part of the problem here is a fundamental misunderstanding of how 
the vast majority of hosts are configured currently.


Speaking for myself, I would say that "explicit" is what the user 
configured and "implicit" is what the is not used-configured.


I haven't seen anyone in the IETF arguing that the moon is made of 
green cheese either. What does your comment have to do with 
anything? Sorry (again) to be blunt, but the IETF pounding the "this 
thing is bad!" drum is not a particularly effective tool. [1]


I hope that "market forces", whatever that means, is not the main 
argument to dispel problems.


We have to be realistic about how and where our influence is 
relevant, and more importantly how and where it is not. Detailing 
the technical problems with the proposal is relevant IETF work, but 
that job has already been done more thoroughly by my esteemed former 
colleagues on the SSAC.


I don't have any influence.  I take no position on the SSAC 
report.  What I did was to read all the IETF specifications 
referenced in the draft and write a draft.  It does not bother me to 
be unrealistic. :-)



It is up to those who decide to decide whether dotless domains is a good
idea that will gain traction or a bad idea that will go away on it own.


You vastly overestimate your own importance in the grand scheme of 
things. Don't worry, it's a common human problem. :)  Rather than 
repeating my point for the third time, see what I wrote just above.


I left in the paragraph that was quoted for context.  The text says 
"those who decide".  I don't have anything to do with the decision 
about dotless domains.  As I am not important it is unlikely that I 
might overestimate my importance. :-)  I don't know the grand scheme 
of things and I do not need to know the grand scheme of things.


Regards,
S. Moonesamy

The case of dotless domains (was: Dotless Domain conflict with user searching and branding)

2013-07-14 Thread S Moonesamy


At 06:53 14-07-2013, Yoav Nir wrote:

http://tools.ietf.org/html/draft-moonesamy-dotless-domains-00


That memo discusses about the case of the dotless domains in terms of 
the technical standards.  Comments are welcome.


At 13:11 13-07-2013, Ofer Inbar wrote:

What this brings to mind is that we used to have implicit DNS domain
search in the early days of DNS.  When edu.com accidentally hijacked
a huge chunk of the Internet, most of the net very quickly got rid of
implicit search, and we got the explicit DNS search feature that many
people are discussing now.


Yes.


If some new TLD gets used in a dotless fashion in a way that truly
does cause major trouble, I expect we'll see sites all over the net
quickly deploying DNS resolvers that discard A, , or MX records
at the top level, to protect their users.


There is already deployed code to do that.

At 20:14 14-07-2013, Doug Barton wrote:
It is unarguably true that as things currently stand there will be 
"problems" with dotless domains. How widespread, and how serious 
those problems become is yet to be seen.


I haven't seen anyone in the IETF arguing that sufficient market 
demand overrides comments about problems that will appear.


So either this is a good idea that will gain traction, and therefore 
appropriate software support; or it is a bad idea that will go away 
on its own. Either way, making a fuss


It is up to those who decide to decide whether dotless domains is a 
good idea that will gain traction or a bad idea that will go away on it own.


At 20:25 14-07-2013, Dave Crocker wrote:
In contrast, assertions about "market demand" ensuring that 
"software folks... will make them work" rests on a fuzzy concept of 
market forces -- for example, the market of users isn't likely to be 
issuing a formal or informal 'demand' about any of this, and a model 
of altering installed-base behavior that has, I believe, has no 
historical precedent.


Yes.

It is, in fact, possible that Marshall Rose was wrong and that for 
some things, there is no possible thrust sufficient to make pigs 
fly, or at least not without killing an extraordinary number of other pigs.


:-)

Regards,
S. Moonesamy

Re: IAB Statement on Dotless Domains

2013-07-10 Thread S Moonesamy

Hello,
At 11:59 10-07-2013, Russ Housley wrote:
The IAB has made a statement on dotless domains. You can find this
statement here:

http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

There was a report from the ICANN the Security and Stability Advisory
Committee in February 2012 on "Dotless domains". An IAB statement
about "Dotless Domains Considered Harmful" is issued over a year
after that. I am surprised that a draft of the statement was not
brought to the attention of the IETF participants who have been
discussing about the use of dotless domains on the SMTP mailing
list. To be fair, I should have read the minutes and enquired about
the matter instead of commenting about the matter after the fact.

ICANN announced in May 2013 that "it has commissioned a study on the
potential risks related to dotless domain names based on SAC 053
report". The announcement mentioned that in June 2012 "the ICANN
Board directed staff to consult with the relevant communities
regarding implementation of the recommendations in SAC 053". One of
the recommendations in SAC0533 is that:

"As a result, the SSAC also recommends that the use of DNS
resource records such

as A, , and MX in the apex of a Top-Level Domain (TLD) be contractually
prohibited where appropriate and strongly discouraged in all cases."

I don't know whether the ICANN Board considers the IETF as a relevant
community. I read several IETF Fluff Area mailing lists. I did not
see any message about a consultation regarding that recommendation.

The IAB statement mentioned that:

"The IAB believes that SSAC report SAC053 [SAC053] is a reasonable summary
of the technical problems that arise from the implementation of dotless
domains."

I would describe the report as an adequate summary of the technical
problems for a non-technical audience.

RFC 5321 was published in October 2008. SAC053 references RFC 2821
on Page 7. It is odd that the members of the ICANN Security and
Stability Advisory Committee were not aware that RFC 2821 was then
considered as obsolete for over three years.

From the IAB statement:

"SAC053 does not, however, discuss the standards compliance aspect."

And from SAC053:

"Thus standard-compliant mail servers would reject emails to addresses such
as user@brand."

The report mentions a standards compliance aspect.

From the IAB statement:

"The use of SHOULD for [RFC 1123 section 6.1.4.3] (b) is a recommendation
against doing DNS queries for dotless domains. RFC 2119 explains
the meaning

of SHOULD as follows:"

and the statement quotes text from RFC 2119. The meaning of the
"SHOULD" in RFC 1123 is explained in RFC 1123. RFC 1123 was
published in October 1989. RFC 2119 was published in March 1997. I
suspect that the IAB may have used time-travel technology for the
"discussion of standards conformance".

The IAB issued a statement about "The interpretation of rules in the
ICANN gTLD Applicant Guidebook" in February 2012. That report also
refers to "one of the specific TLD requirements set by RFC 1123". It
seems to me that the conversations with subject matter specialists
were mainly about adding a "string" to the Root Zone and that the
protocol-related issues might not have been conveyed clearly given
that the IAB issued the statement about "dotless domains" in July 2013.

The IAB previously mentioned that it maintains its chartered
responsibility about the RFC Series. The IAB statement refers to
RFCs from the www.faqs.org website. It might be better to reference
the rfc-editor.org links or else there may be a perception that the
IAB is not aware of the most stable reference available.

Regards,
S. Moonesamy

Re: Regarding call Chinese names

2013-07-10 Thread S Moonesamy


Hi Deng Hui,
At 17:04 10-07-2013, Hui Deng wrote:
We submitted two drafts to help people here to correctly call 
chinese people names:


http://tools.ietf.org/html/draft-deng-call-chinese-names-00

   http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00


I would like to thank you and your co-author on taking the initiative 
to write the drafts.  I don't know whether I am western or not. :-)


In Section 3 of draft-deng-call-chinese-names-00:

  'Two generic titles that have similar meanings to "Mr." and
   "Ms./Mrs." are "Xian1sheng1" and "Nv3Shi4".'

  "(1,2,3,4 in this section will be explained in next section)

There are digits in two words in the above.  I suggest making the 
comment about the numbers clearer by mentioning that the digits are 
intentional and they are used to denote the tone.


Regards,
S. Moonesamy

Re: Final Announcement of Qualified Volunteers

2013-07-09 Thread S Moonesamy


At 06:49 09-07-2013, Ted Lemon wrote:
I find the presumption that IETF attendees employed by companies 
that send large number of attendees are robots to be somewhat 
distasteful.   It also doesn't match my experience.   I am sure that 
_some_ attendees from large companies are just as partisan as you 
fear, but some are not.   So I am not convinced that your proposal 
would have a good outcome.


I fixed the nomcom-chair-2013 email address as it does not make sense 
to send an email to an invalid address.


When designing a random selection a person has to ensure that the 
selection is such that the unbiased nature is publicly 
verifiable.  As John Klensin mentioned "four companies account for 
44.3% of the volunteers".  A similar question was raised by Sam 
Hartman previously.  When I looked at the affiliations over the years 
I noticed that two companies can easily get 40% of the vote.


The IETF works on the presumption of good faith.  Would a significant 
number of attendees from large companies adopt a partisan 
approach?  It's difficult for the public to determine that.  I'll 
change the question: does anyone believe that the average attendee 
from a large company will take a decision which is in the interest of 
the IETF Community even though that decision conflicts with what 
would be in the interest of the company?


That's not the better question though.  What is NomCom about?  The 
possible answers are not in the RFCs.


Anyway, the initial message was about having a broad pool and doing 
an unbiased selection from it.  The pool may have less people but it 
is broader in the sense that there would be people from all walks of 
the IETF.  I think that's what Jari Arkko might be referring to when 
he writes the word "inclusive".


Regards,
S. Moonesamy

Re: The Nominating Committee Process: Eligibility


Hi Abdussalam,
At 12:16 27-06-2013, Abdussalam Baryun wrote:
I support the draft, it will give all participants from all the 
world equal opputunity. I made input related to this on the list 
because I found that I am remote participant and there was limits 
and conditions which I don't want. However, there may be some 
reasons that IETF done it that way which the draft may need to 
clarify and solve,


Thanks for explaining why you support the draft.  I am going to list 
some questions.  Please read them as points to consider.  There isn't 
any obligation to provide comments.


 - What is your opinion about helping the "pie get larger"?

 - What would be an acceptable way of determining whether someone
   has been contributing to the IETF over a period of five meetings?

 - Dave Cridland suggested that working groups provide a smallish set of
   volunteers each for the selection process.  Is it okay to leave it
   to the working group chair to make the decision?

Regards,
S. Moonesamy

RE: The Nominating Committee Process: Eligibility


At 12:38 27-06-2013, Adrian Farrel wrote:

I think you can rely on each person actually on NomCom to speak their mind and
deliver from their experience (and we can rely on the NomCom chair 
to tease that

out). So surely we can say something like:
2 old-timers chosen randomly from a list of old-timers
4 people who have been around the IETF a lot (e.g. 3 out of last 5 meetings)
3 people who have worked in the IETF quite a bit (e.g.  front page 
of > 2 RFCs)
3 people who have evidence of participation in technical work on 
mailing lists.

Each person is only allowed to be placed in one pool before selection.


I'll comment on the above.  I have seen the request about 
reconsidering Section 2 of the draft and I am not ignoring it.


Someone would have to create a list of old-timers.

I think I understand what you mean by "around the IETF a lot".  I'll 
skip that for now.


The front page of more than two RFCs can create an incentive to:

 (a) generate more RFCs

 (b) add more names to the author list

There are a few ideas (including the above quoted text) which could 
be combined to figure out one or more workable alternatives.


Regards,
S. Moonesamy

Re: The Nominating Committee Process: Eligibility

t would be good to figure out what is really needed and 
desired and then work out the details.



conclude --as I think some have suggested-- that we don't want
often-remote volunteers on the Nomcom no matter what, or that we
don't want people who cannot just about guarantee physical
attendance at all relevant meetings to serve on the Nomcom, or
that we are unwilling to consider relaxing the current 3 of 5
rule for other reasons, then I'd argue that putting energy into
defining appropriate criteria for being a remote attendee is
pretty much a waste of time.  If we do decide we want to open
the door to remote attendees on the Nomcom and later discover
that we can't agree on criteria, that is just how it goes.


Yes.


In principle, one could consider the "do we want this" and "what
would the criteria be" questions in either order.  In practice,
I think the former question is the more important and should be
considered first because it informs how we really feel about
diversity and the role of participants who don't attend a lot of
f2f meetings.   I also believe that, while I might be very
difficult to come up with a perfect definition of remote
participation on which we could all agree, coming up with a
definite that would be at least as good at discriminating
between actual remote participants and contributors and other
sorts of folks as the current 3 of 5 rule is at discriminating
between those who understand the IETF culture and those who
don't.


In my opinion the easier path is to focus on contributors.  The IETF 
culture angle is  controversial because it is like saying that the 
person has to adopt North America culture.



Well, I agree with all of that in principle.  In practice, I
don't think the combination of a heavy Nomcom workload and long
period of commitment with the 3 of 5 rule has served us very
well in recent years, especially in terms of guaranteeing that
the criteria you think are important are met.   I think we would
be better off with requirements that made it more feasible for
people like you to volunteer to serve on the Nomcom on the basis
of long-term understanding of the culture, a history of
participating in a diverse collection of WGs, a few less f2f
meetings, and some remote participation.  Instead, the 3 of 5


The above does not require any process changes.


rule and those other factors have brought us Nomcoms with a
large fraction of the volunteer pool being folks with far less
experience and perspective and a need to rely almost completely
on questionnaires and interviews rather than knowledge.  I don't


Yes.


It is certainly possible that considering and making some
changes could make things worse.  But they could also make
things better.  And, IMO, merely having a serious conversation
about what we would like our criteria to be and what we are
trying to optimize is useful.   If nothing else, some relative
newcomers might learn something useful about the culture from
the conversation and how we carry it out.


A side-effect of the discussion could be about enabling new people to 
learn something useful.  If the only way to learn something useful 
about the culture is to have a meeting near your home or to have 
extensive travel resources to get to a meeting the IETF is 
restricting itself to people who work for large vendors.  I leave it 
to the reader to determine whether it leads to large corporate 
control of IETF standards.


I'll quote an extract of a message from the IETF Chair (presently IAB 
Chair) and IAOC Chair:


  "The IETF has always used the Internet to do its work, and remote
   participation is no exception."

Is that correct or is the definition of the IETF everything except 
the IAB, IESG, IAOC, IETF Trust and NomCom?


The IETF mentioned that:

  "Currently, the IETF meets in North America, Europe, and Asia. The intention
   is to meet once a year in each region, although due to scheduling issues
   there are often more meetings in North America and fewer in Asia 
and Europe."


The intention is commendable.  In my opinion it is what happens in 
practice that matters.  I'll quote Olaf (I forgot the actual words): 
the IAB publishes its minutes so that anybody who cares can see what 
the IAB is doing.  If there is a scheduling issue people might 
understand it.  If there are two or three of four scheduling issues 
some people might still be understand it.  If there are systematic 
scheduling issues people will no longer believe what Olaf is saying.


Regards,
S. Moonesamy

Re: The Nominating Committee Process: Eligibility


At 09:44 27-06-2013, Eggert, Lars wrote:
sorry, but it's silly to attempt to propose that remote attendees be 
permitted to volunteer for NomCom without defining what defines a 
remote attendee.


Agreed.

The issue you are raising - that limiting the NomCom pool to recent 
attendees of physical IETF meetings may have downsides - is valid. 
But at least the requirements the current policy sets are clearly defined.


Until you nail down what exactly defines a remote attendee, I can't 
really form an opinion on whether allowing them into the NomCom pool 
is a good idea or not.


What I did in the initial draft is to work from the text already in 
RFC 3777.  It has been mentioned by several people that participation 
is a way for somebody to get IETF experience.   The question is how 
that participation can be defined.


At 10:00 27-06-2013, Paul Hoffman wrote:
Then maybe we should wait for you to do so. This discussion is kind 
of pointless if we don't have shared definitions.


I think that the NomCom eligibility criteria should not discriminate 
between any contributor to the IETF Standard Process.  The view I got 
from a previous discussion of the draft is that "people from emerging 
regions are disenfranchised; that's how IETF culture works".


Regards,
S. Moonesamy

Re: The Nominating Committee Process: Eligibility

ing Committee Operation",
   Paragraph 1 of Rule 14, is replaced as follows:

  Members of the IETF community become eligible for the NomCom by
  having attended at least 3 of the last 7 IETF meetings in person.

  Once a person has become eligible for NomCom, they retain their
  elibility to NomCom by attending at least 1 of the last 4 IETF meetings
  in person, and at least 3 of the last 5 meetings in person or remotely.

  Should a person lose eligibility for NomCom, they return to 
not-eligible.


(We could, true to form, describe this as a state machine with three states,
or even a simpler to write in Verilog one with 7-8 states)


I agree that new people can have difficulty understanding how things 
fit together.


My quick response to the suggestion is no.  The reason is because of 
the way "attended" is being interpreted and because I don't think 
that it is good to have a high barrier of entry.



I have lowered the bar to remain eligible such that a person who not travel
for 12 months (such as someone on maternity/paternity leave. Civilized
countries get at least 1 year..) could remain eligible.


Thanks for the explanation.  There was an unrelated discussion about 
parents finding it difficult to attend IETF meetings.


At 06:24 27-06-2013, Michael Richardson wrote:

2) for the November meeting, the nomcom *itself* must be present.
   I think it unrealistic to think that the nomcom itself could
   be remote for that meeting.  For the summer and march meeting,
   the nomcom could be anywhere.


When is it summer? :-)

At 06:48 27-06-2013, John C Klensin wrote:

While it risks taking us into a statistical rathole, I think
that notions like the above may be the sort of thing we should
look at.


I left the door open for that.


More broadly, I think we may need to try to figure out what we
really want and need on or from the Nomcom in this decade
(remembering that the system was designed for the rather
different times and IETF composition of the early 1990s and has
been tuned in minor ways but not carefully and openly reviewed
since) and then try to devise criteria to match.   It seems to
me that may require looking at separate aspects of things rather
than trying to come up with a single surrogate for everything.


Yes.


We might want to look at whether some collections of
participants should be guaranteed representation or weighted
more heavily in the selection calculations (whether voting or
otherwise).  That raises the risk that SM identifies of pushing
us toward a Nomcom as a representative body of constituencies
demanding slots, but the advantages seem very strong for Dave
Crocker's proposal to guarantee a certain level of expertise and
some ideas to be sure that the perspective of remote
participants or other underrepresented populations are heard.
The question is how to find the right balance and then reach
sufficient consensus around the justification that we can hold
the line.   Not easy, but, at least IMO, probably worth the
investment it would take.


I need to get back to something Dave Crocker wrote.  There was a 
discussion (not on an IETF mailing list) which pointed to 
constituencies and representativity.  I don't think that excluding 
people is a good idea.  The last sentence, in a way, sums up what the 
proposal will have to achieve.



Similarly, I'm pretty sure that "groks the IETF" [1] is an
important and useful criterion.  I don't think "3 of last 5" is
a valid exclusive surrogate.  Perhaps what is needed is a list


Yes.


If we separated the "IETF culture" requirement, I still think
that some level of participation, even face to face
participation is important.  I don't think that 3 face to face
meetings in 5 is needed for people who already understand the
culture; maybe some combination of remote participation and less
frequent attendance should be equally acceptable.


The "IETF culture" requirement is ambiguous.  Arturo asked a good 
question.  I would describe the side discussions as being about 
understanding why the IETF is doing X.



"Participation" is similar.  If we think it is important, then
someone who is actively contributing to mailing lists and
document reviews and who is showing up in meeting Jabber logs
with useful comments is, IMO, a more appropriate Nomcom member
than someone whose company pays registration fees and travel
expenses and who then shows up at meetings and either goes to
the beach or sits in a few WG meetings reading email.  I don't
know how to eliminate the second (perhaps others have ideas) but
I can think of ways to identify the former as long as they are
not the exclusive "minimum participation" admission criteria.


My focus is "participation".


I would just hope that we don't fall into the trap of focusing
on what is easy to measure and quantify rather than what is
important and a good measure of what we are looking for.   It is


I'll add that the trap is also focusing on the details prematurely.

Regards,
S. Moonesamy

Re: The Nominating Committee Process: Eligibility


Hi Alejandro,
At 05:42 27-06-2013, alejandroacostaal...@gmail.com wrote:
  First, as a comment, I guess there is people who follow more IETF 
remotely than other in place.


Yes.

Here's is an extract from a Jabber log:

  "I don't think I've seen a WG chatroom this full before
   Well the future of the free world is at stake here :-)"


  Second, I like this idea of changing the threshold.


Thanks for reading the draft and providing feedback.

  Third, In the other hand, since there are several positions that 
are fill using this RFC maybe we can place a testbed. 50% can be 
fill using the current way and 50% using the proposed way, sounds 
crazy but it might be a good beginning.


I don't think that it sounds crazy.  A good beginning is when people 
make suggestions like you did.  I don't know yet whether I will say 
okay to the idea.  I would like to read all the suggestions, 
including yours, and then decide.


Regards,
S. Moonesamy

Re: The Nominating Committee Process: Eligibility


Hi Arturo,
At 03:00 27-06-2013, Arturo Servin wrote:

I read the draft and although I like the idea I have some concerns.


Thanks for taking the time to read the draft.  I'll comment below.


Today it is possible to verify that somebody attended to an IETF
meeting. You have to register, pay and collect your badge. However, in
remote participation we do not have mechanisms to verify that somebody
attended to a session.


I am aware of a case where the person attending the IETF meeting is 
not the one who's name is on the badge.  I don't think that there was 
any malice or that it is a problem as that person will not game the system.



Even, if we had a registration similar to the face to face meetings,
it would be difficult to verify that the people attended to a session
remotely (even if you correlated registry vs. jabber/webex logs it would
be difficult to know if it is really the person registred, somebody else
or even a bot). I guess that there would be many ways to game the system.


I do not wish to suggest having registration.  The IETF does not 
require registration to participate in working group discussions.  I 
agree that there can be many ways to game the system.


I will quote the second paragraph of the Introduction section of the draft:

  "The IETF Trust considers any submission to the IETF intended by the
   Contributor for publication as all or part of an Internet-Draft or
   RFC and any statement made within the context of an IETF activity
   [RFC5378].  Such statements include oral statements in IETF sessions
   as well as written and electronic communications, made through a
   Jabber room."

It would be a serious issue, in my opinion, if the IETF cannot 
identify its contributors.  There are people who currently contribute 
through Jabber.  It has never been considered as a problem.



As I said I like the idea and I think that we should try to make it
work. I do not know if all the locks and tools to protect the system
against some sort of abuse should be in the draft or not, but we should
address those (before or in parallel with adopting/working on the draft.)


I agree that you and I should try to make it work.  One of the 
problems of putting all the details in a document is that we lose the 
flexibility to, for example, address some sort of abuse that we did 
not specify clearly at the time the document was written.  I would 
not look for locks and tools to protect the system; I would look for 
something else.


Regards,
S. Moonesamy

The Nominating Committee Process: Eligibility