Eric Burger | 1 Sep 02:37 2011

Re: 2119bis

This highlights an interesting issue as an RFC goes from PS to IS.  I would offer that most SHOULDs in a
document will, if there are real implementations out there, migrate to MUST or MUST NOT.

On Aug 31, 2011, at 9:57 AM, hector wrote:

> I think you are speaking of long term operations where an SHOULD is so widely adopted, it inherently
because a MUST have in all new implementations.  So that vain, sure, eventually the better options
naturally become part of the protocol to the extent the options might be even remove to simplify things.  We
also have the opposite where a SHOULD is implemented but no one users it so eventually, it may be remove as an option.

Attachment (smime.p7s): application/pkcs7-signature, 5313 bytes
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hector | 1 Sep 08:58 2011
Picon

Re: 2119bis

Murray S. Kucherawy wrote:

> Ditto.  And I also see a lot of creative interpretation.  There's little we 
> can do to thwart any of those problems; some people read what they want to 
> read and do so in a vacuum.

+1.

I couldn't agree with you more Murray!

When you consider that its not very hard to find mainstream software, 
or even the one they are using to post mail in the list using well 
established IETF protocols that follows RFC2119 to the letter, it 
makes you wonder if there really a problem with RFC2119. I mean, I 
don't see it myself. It reads pretty clear to me, especially section 6 
with that precise non-ambiguous sentence.

    6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

That last sentence is so clear. Maybe the error is not using an 
uppercase MUST NOT and NOT REQUIRED in that last sentence.  Maybe 
software people need logic statements like:
(Continue reading)

Andrew G. Malis | 1 Sep 13:42 2011
Picon

Re: Last Call: <draft-kompella-l2vpn-l2vpn-07.txt> (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC

Speaking as an individual, the solution in this draft has been has been operationally deployed in a number of service provider networks, and it should be documented in an informational RFC.

Speaking as PWE3 co-chair, I would be happier if this draft required that routers that implement this solution also implement RFC 4447, that RFC 4447 be configured as the default mechanism for pseudowire signaling, and that RFC 4447 was moved from an informational to a normative reference. In practice, I know that routers that implement this also do implement RFC 4447, but I would like to see it in the RFC as well.

Thanks,
Andy


Subject: Date: From: Reply-To: To:
Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
Tue, 30 Aug 2011 10:50:05 -0700
The IESG <iesg-secretary <at> ietf.org>
ietf <at> ietf.org
IETF-Announce <ietf-announce <at> ietf.org>


The IESG has received a request from an individual submitter to consider the following document: - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' <draft-kompella-l2vpn-l2vpn-07.txt> as an 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 <at> ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be sent to iesg <at> ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. The file can be obtained via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1149/ _______________________________________________ IETF-Announce mailing list IETF-Announce <at> ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Keith Moore | 1 Sep 13:46 2011

Re: 2119bis

On Sep 1, 2011, at 2:58 AM, Hector wrote:

>   6. Guidance in the use of these Imperatives
> 
>   Imperatives of the type defined in this memo must be used with care
>   and sparingly.  In particular, they MUST only be used where it is
>   actually required for interoperation or to limit behavior which has
>   potential for causing harm (e.g., limiting retransmisssions)  For
>   example, they must not be used to try to impose a particular method
>   on implementors where the method is not required for
>   interoperability.
> 
> That last sentence is so clear. Maybe the error is not using an uppercase MUST NOT and NOT REQUIRED in that
last sentence.  Maybe software people need logic statements like:

I actually think that the last sentence is overbroad.  There are other defensible reasons to use the 2119
keywords than those enumerated in the document.   And those words can be (and have been) interpreted in such
a way as to compel working groups to fail to make design choices, and to permit too many alternative choices
in implementations.     

Keith
George Willingmyre | 1 Sep 15:16 2011

Re: 2119bis

I offer for consideration the ISO and IEC  requirements for use of  the 
terms   "Shall" ; Shall not"; "Should"; "Should not" ;  "May"; "Need not" ; 
"Can'; "Cannot" in ISO and IEC standards.

This document explains why ISO/IEC selects "Shall" and "Shall not" rather 
than "Must" and "Must not" to denote mandatory requrrments.

"Do not use "must" as an alternative for "shall". (This will avoid any 
confusion  between the requirements of a document and external statutory 
obligations.)"

It is in the interests of IETF to contemplate and perhaps reference this 
ISO/IEC document somehow in our defnition of the terms below

2.1.  MUST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  MUST NOT  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.3.  SHOULD  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.4.  SHOULD NOT  . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.5.  MAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

George T. Willingmyre, P.E.
President, GTW Associates
Spencerville, MD USA 20868
301.421.4138
www.gtwassociates.com

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
George Willingmyre | 1 Sep 15:17 2011

Re: 2119bis

I offer for consideration in the attachment  the ISO and IEC  requirements 
for use of  the
terms   "Shall" ; Shall not"; "Should"; "Should not" ;  "May"; "Need not" ;
"Can'; "Cannot" in ISO and IEC standards.

This document explains why ISO/IEC selects "Shall" and "Shall not" rather
than "Must" and "Must not" to denote mandatory requirements.

"Do not use "must" as an alternative for "shall". (This will avoid any
confusion  between the requirements of a document and external statutory
obligations.)"

It is in the interests of IETF to contemplate and perhaps reference this
ISO/IEC document somehow in our definition of the terms below

2.1.  MUST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  MUST NOT  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.3.  SHOULD  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.4.  SHOULD NOT  . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.5.  MAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

George T. Willingmyre, P.E.
President, GTW Associates
Spencerville, MD USA 20868
301.421.4138
www.gtwassociates.com

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Mykyta Yevstifeyev | 1 Sep 15:48 2011
Picon

Re: 2119bis

George,

We currently use MUST in regular cases and SHALL when we either want not to create confusion where non-normative "must" is used or for aesthetic reasons, eg. to make a requirement look not so strict as MUST implies (even though formally they both have similar force).  I personally use SHALL when I mean "it is to be so" and not strict "it is mandatory and obligatory and compulsory and <...> to be so".

CAN and CANNOT are an interesting idea, but they have little in common with conformance.  Current 2119 language, as primarily used in <http://tools.ietf.org/html/rfc1123#page-11>, was intended to clear up the requirements on support of particular feature(s).  Yes, it is sometimes desired to express possibility and allowance, but IMO simple "can" and "cannot" are fine for this purpose.

I don't actually think Annex H of <I don't know what since you're providing only part of it> should be referenced in 2119bis.

Mykyta Yevstifeyev

01.09.2011 16:17, George Willingmyre wrote:
I offer for consideration in the attachment  the ISO and IEC  requirements for use of  the
terms   "Shall" ; Shall not"; "Should"; "Should not" ;  "May"; "Need not" ;
"Can'; "Cannot" in ISO and IEC standards.

This document explains why ISO/IEC selects "Shall" and "Shall not" rather
than "Must" and "Must not" to denote mandatory requirements.


"Do not use "must" as an alternative for "shall". (This will avoid any
confusion  between the requirements of a document and external statutory
obligations.)"


It is in the interests of IETF to contemplate and perhaps reference this
ISO/IEC document somehow in our definition of the terms below


2.1.  MUST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.2.  MUST NOT  . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.3.  SHOULD  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.4.  SHOULD NOT  . . . . . . . . . . . . . . . . . . . . . . . . 4
    2.5.  MAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4






George T. Willingmyre, P.E.
President, GTW Associates
Spencerville, MD USA 20868
301.421.4138
www.gtwassociates.com



_______________________________________________ Ietf mailing list Ietf <at> ietf.org https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
George Willingmyre | 1 Sep 16:00 2011

Re: 2119bis

While we are on the topic of definitions I  hoped to stimulate thinking and we can reach the conclusion that best meets our needs.
 
The source parent  document is at the URL on the ANSI web site http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/International%20Standardization/ISO/ISO_IEC_Directives_Part2.pdf

ISO/IEC Directives, Part 2 

Rules for the structure and drafting of International Standards

 

 
 
 
George T. Willingmyre, P.E.
President, GTW Associates
Spencerville, MD USA 20868
301.421.4138
www.gtwassociates.com
----- Original Message -----
Sent: Thursday, September 01, 2011 9:48 AM
Subject: Re: 2119bis

George,

We currently use MUST in regular cases and SHALL when we either want not to create confusion where non-normative "must" is used or for aesthetic reasons, eg. to make a requirement look not so strict as MUST implies (even though formally they both have similar force).  I personally use SHALL when I mean "it is to be so" and not strict "it is mandatory and obligatory and compulsory and <...> to be so".

CAN and CANNOT are an interesting idea, but they have little in common with conformance.  Current 2119 language, as primarily used in <http://tools.ietf.org/html/rfc1123#page-11>, was intended to clear up the requirements on support of particular feature(s).  Yes, it is sometimes desired to express possibility and allowance, but IMO simple "can" and "cannot" are fine for this purpose.

I don't actually think Annex H of <I don't know what since you're providing only part of it> should be referenced in 2119bis.

Mykyta Yevstifeyev

01.09.2011 16:17, George Willingmyre wrote:
I offer for consideration in the attachment  the ISO and IEC  requirements for use of  the
terms   "Shall" ; Shall not"; "Should"; "Should not" ;  "May"; "Need not" ;
"Can'; "Cannot" in ISO and IEC standards.

This document explains why ISO/IEC selects "Shall" and "Shall not" rather
than "Must" and "Must not" to denote mandatory requirements.


"Do not use "must" as an alternative for "shall". (This will avoid any
confusion  between the requirements of a document and external statutory
obligations.)"


It is in the interests of IETF to contemplate and perhaps reference this
ISO/IEC document somehow in our definition of the terms below


2.1.  MUST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.2.  MUST NOT  . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.3.  SHOULD  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.4.  SHOULD NOT  . . . . . . . . . . . . . . . . . . . . . . . . 4
    2.5.  MAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4






George T. Willingmyre, P.E.
President, GTW Associates
Spencerville, MD USA 20868
301.421.4138
www.gtwassociates.com



_______________________________________________ Ietf mailing list Ietf <at> ietf.org https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Barry Leiba | 1 Sep 16:29 2011
Picon

Re: 2119bis

Mykyta says...
> I personally use SHALL when
> I mean "it is to be so" and not strict "it is mandatory and obligatory and
> compulsory and <...> to be so".

But, see, this is exactly the sort of problem we're talking about.
You make some sort of semantic (not just stylistic) distinction
between MUST and SHALL.  Yet RFC 2119 does not; it defines them as
synonyms.  In a document that uses these terms according to RFC 2119,
they mean exactly the same thing, and they are interchangeable.

Barry
Mykyta Yevstifeyev | 1 Sep 16:35 2011
Picon

Re: 2119bis

01.09.2011 17:29, Barry Leiba wrote:
> Mykyta says...
>> I personally use SHALL when
>> I mean "it is to be so" and not strict "it is mandatory and obligatory and
>> compulsory and<...>  to be so".
> But, see, this is exactly the sort of problem we're talking about.
> You make some sort of semantic (not just stylistic) distinction
> between MUST and SHALL.  Yet RFC 2119 does not; it defines them as
> synonyms.  In a document that uses these terms according to RFC 2119,
> they mean exactly the same thing, and they are interchangeable.

Yes, you're right - they both have similar force.  But SHALL *looks* 
like being a bit more lightweight variant of MUST; whereas we 
differentiate how they'll be perceived by the human reader, SHALL still 
means that the implementor is obliged to what it is applied to.  I mean 
only stylistic distinction here.

Mykyta

>
> Barry
>

Gmane