Subject: Re: [edu-discuss] solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt -

From: SM <[email-masked]>
Date: Tue, 07 May 2013 01:18:54 -0700

Hi Hosnieh,

[Following up on [email-masked]]

At 00:50 07-05-2013, Hosnieh Rafiee wrote:
>In my opinion, it is better to update the current RFCs or obsolete them
>instead of adding more specifications which will result on confusing
>vendors. Of course, it is my point of view and some people are disagree with
>that. They would like to have several optional standards and let the
>implementers to choose.

Proposed Standards were supposed to be "optional".  Implementers 
choosing to implement them was a good test for running code (code 
which is actually used on the Internet).  The specifications can then 
be published as Standard.  If you don't have time to track all the 
Proposed Standard you could implement the Standard and achieve at 
least minimum interoperability.  It does not work in practice.  There 
isn't any Standard for IPv6.  The Standard for SMTP (email) is old 
and it is not worth basing an implementation on that.

I am curious about what you find difficult about IETF 
specifications.  Note that I am not going to disagree with your 
opinion or argue that what you said is wrong. :-)

Regards,
-sm

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 7 May 2013 10:41:57 +0200

Hi,

> >In my opinion, it is better to update the current RFCs or obsolete 
> >them instead of adding more specifications which will result on 
> >confusing vendors. Of course, it is my point of view and some people 
> >are disagree with that. They would like to have several optional 
> >standards and let the implementers to choose.
> 
> isn't any Standard for IPv6.  The Standard for SMTP (email) is old and it
is not worth basing an implementation on that.
> 
> I am curious about what you find difficult about IETF specifications.  
> Note that I am not going to disagree with your opinion or argue that 
> what you said is wrong. :-)
> 

As you stated here, there are some old RFCs that, in my opinion, we do not
know whether or not they still address today's minimum requirements. There
are also some vendors that still using them because they did not see any
update on them. This means we are adding more and more standards while we do
a few efforts to check the old standards and obsolete them or update them. I
do not have any problem with having several options. But I do think that
addressing the current RFCs has more priority on adding new specifications.
In other word, to say whether or not the current RFCs can still address our
needs or they need a few modifications to address our needs, has higher
priority than trying to come up with something that might have the same
impact as we resolve the problem with the current RFCs.  

I heard from some people that their problem of not addressing the old RFC is
backward compatibilities. In my opinion, It is the choice of vendors to
improve their old implementations or just leave it as it is. But by
addressing those RFCs at least the customers know that they did not choose
the best option. This means that the customers will force vendors to improve
their current implementations. Then instead of having thousands of RFCs we
will have some that we can rely on and we are sure that they are not
something not useful. When something does not have our today's requirement
why we need to think about that?! 

Regards,
Hosnieh