Subject: [savi] Requirements level for data-packet-triggered binding creation

From: Christian Vogt <[email-masked]>
Date: Thu, 10 Jun 2010 16:21:19 -0700

Folks:

In our foregoing discussion, we found that data-packet-triggered binding
creation would help SAVI solutions minimize loss of legitimate packets. 
But a question that is yet to be answered is on the requirements level
that data-packet-triggered binding creation should have:  Should it be a
MUST, a conditional MUST, a SHOULD, or a MAY?  The foregoing discussion
indicates that the working group would prefer not to use a MUST, since
the extra complexity of data-packet-triggered binding creation is not
required in all cases.  The working group chairs would hence like the
working group to consider the following two options more closely:

(1) A conditional MUST, allowing implementations to omit data-packet-
    triggered binding creation if the SAVI device is known to directly
    attach to hosts.

(2) The specification of two modes -- a loose mode and a strict mode --,
    whereby only the strict mode implements data-packet-triggered
    binding creation.  Implementations can support either or both modes.

Please share your view.

- Christian, for Jean-Michel and Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jun 2010 19:25:52 -0400

My basic reaction is that the conditional-MUST is the best compromise on 
this.  I will not calim complete happiness, but there is no rule that 
any of us have to be completely happy with any of the answers.

I find loose mode extremely undesirable.  The value benefit from loose 
mode is weak and hard to characterize.  There are many gaps in the 
protection, and I do not find it a useful point in the spectrum of 
choices.  (The goal is NOT to write a standard that allows every 
possible behaviors.  Such a standard is not useful, and does not promote 
interoperability or predictability.)

Yours,
Joel M. Halpern

Christian Vogt wrote:
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 11 Jun 2010 11:42:23 +0200

+1

El 11/06/10 1:25, Joel M. Halpern escribió:
> My basic reaction is that the conditional-MUST is the best compromise 
> on this.  I will not calim complete happiness, but there is no rule 
> that any of us have to be completely happy with any of the answers.
>
> possible behaviors.  Such a standard is not useful, and does not 
> promote interoperability or predictability.)
>
> Yours,
> Joel M. Halpern
>
> Christian Vogt wrote:
>> Folks:
>>
>> creation would help SAVI solutions minimize loss of legitimate 
>> packets. But a question that is yet to be answered is on the 
>> requirements level

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Jun 2010 21:04:30 +0900

what is the difference between a "conditional must" and a "should"?

I would recommend staying with defined terms...

On Jun 11, 2010, at 6:42 PM, marcelo bagnulo braun wrote:

>> My basic reaction is that the conditional-MUST is the best compromise on this. 

http://www.ipinc.net/IPv4.GIF

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jun 2010 09:29:53 -0400

I have no problem with using "SHOULD... unless explicit condition" which 
is indeed the way we usually say this here.  I was simply separating the 
phrasing debate from the meaning debate.

Yours,
Joel

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Jun 2010 08:57:57 -0700

+1

    Erik

On 06/10/10 04:25 PM, Joel M. Halpern wrote:
> this. I will not calim complete happiness, but there is no rule that any
> of us have to be completely happy with any of the answers.
>
> choices. (The goal is NOT to write a standard that allows every possible
> behaviors. Such a standard is not useful, and does not promote

---

From: Fred Baker <[email-masked]>
Date: Sat, 12 Jun 2010 03:25:44 +0900

OK.

The way we usually state this things is that something "MUST" be true if it simply MUST be true and something will not operate correctly if it is not. "A router MUST have a route table". Something "SHOULD" be true or we "RECOMMEND" that something be true if we would like to say "MUST" but we think there are exceptional cases. "SHOULD...unless <condition>" seems to fit the second model and has us spelling out some of the exceptional cases.

On Jun 11, 2010, at 10:29 PM, Joel M. Halpern wrote:

> I have no problem with using "SHOULD... unless explicit condition" which is indeed the way we usually say this here.  I was simply separating the phrasing debate from the meaning debate.
> 
> Yours,
> Joel
> 
> Fred Baker wrote:

---

From: "Bi Jun" <[email-masked]>
Date: Sat, 12 Jun 2010 12:29:34 +0800

Hi All,

Thanks to Fred's analysis.

I think Fred's suggestion: "SHOULD...unless <condition>"
is more suitable for the savi data-trigger case, because really this it is 
not implementable for most of current *access switches*.

As an operator, we do need access switches (which are cheaper) widely to be 
installed savi functions as the *first-hop-switch*, in this scenario the 
data-trigger function is nearly no use (though I understand the data-trigger 
is needed in some deployment topology). This scenario is CNGI-CERNET2 savi 
deployment scenario in 100 university campus network as I presented in the 
past savi WG meetings.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Fred Baker" <[email-masked]>
Sent: Saturday, June 12, 2010 2:25 AM
To: "Joel M. Halpern" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] Requirements level fordata-packet-triggered	bindingcreation> OK.
>
> The way we usually state this things is that something "MUST" be true if 
> it simply MUST be true and something will not operate correctly if it is 
> not. "A router MUST have a route table". Something "SHOULD" be true or we 
> "RECOMMEND" that something be true if we would like to say "MUST" but we 
> think there are exceptional cases. "SHOULD...unless <condition>" seems to 
> fit the second model and has us spelling out some of the exceptional 
> cases.
>
>
>
>>>>> on this.

---

From: "Guang Yao" <[email-masked]>
Date: Sat, 12 Jun 2010 12:47:09 +0800

+1 

Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fred
> Baker
> Sent: Saturday, June 12, 2010 2:26 AM
> To: Joel M. Halpern
> Cc: [email-masked]
> Subject: Re: [savi] Requirements level for data-packet-triggered binding
> creation
> 
> OK.
> 
it
> simply MUST be true and something will not operate correctly if it is not.
"A
> router MUST have a route table". Something "SHOULD" be true or we
fit
> the second model and has us spelling out some of the exceptional cases.
> 
> 
> 
is
> indeed the way we usually say this here.  I was simply separating the
phrasing
> debate from the meaning debate.
> >
> > Yours,
> > Joel
> >
> > Fred Baker wrote:
on
> this.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 12 Jun 2010 11:16:33 +0200

El 11/06/10 20:25, Fred Baker escribió:
> OK.
>
> The way we usually state this things is that something "MUST" be true if it simply MUST be true and something will not operate correctly if it is not. "A router MUST have a route table". Something "SHOULD" be true or we "RECOMMEND" that something be true if we would like to say "MUST" but we think there are exceptional cases. "SHOULD...unless<condition>" seems to fit the second model and has us spelling out some of the exceptional cases.
>
>
>    

My understanding is that the qualified should is used in the following 
way. You SHOULD do X and if you don't here is a list of bad things that 
can happen. If you don't care about those things, you can disregard the 
reccoemndation.

The conditional MUST as i read it, is you MUST do X unless you are under 
these conditions and this implies that the interop is affected unless 
you are under the described conditions.

I think these are somehow different.

But, if i recall properly, the conditional MUST was Dave Thaler 
suggestion, so maybe he can describe what he has in mind.

Regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Sun, 13 Jun 2010 12:04:46 +0800

Actually I have some opinion on the options, loose mode is not an
alternative of data-trigger.

Data packet trigger is a way to recover binding, however, the savi mode,
loose or strict, is to determine how to use the binding. In loose mode, data
trigger can also be used to recover binding.

Thus, I think this voting should focus on the requirements level "should" or
"conditional MUST", but not "loose mode" or " data trigger". Or, "should" or
"conditional must" in strict mode, "should" or "conditional must" in loose
mode.

Best regards,
Guang

> Christian Vogt
> Sent: Friday, June 11, 2010 7:21 AM
> To: SAVI Mailing List
> Cc: Jean-Michel Combes
> Subject: [savi] Requirements level for data-packet-triggered binding
creation

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Jun 2010 11:44:27 +0200

An example of what i understand is a conditional MUST can be foudn for 
instance in RFC4862, where it reads:

5.4.  Duplicate Address Detection

    Duplicate Address Detection MUST be performed on all unicast
    addresses prior to assigning them to an interface, regardless of
    whether they are obtained through stateless autoconfiguration,
    DHCPv6, or manual configuration, with the following exceptions:

    -  An interface whose DupAddrDetectTransmits variable is set to zero
       does not perform Duplicate Address Detection.

    -  Duplicate Address Detection MUST NOT be performed on anycast
       addresses (note that anycast addresses cannot syntactically be
       distinguished from unicast addresses).

i.e. you MUST do X except in the following condtions.

(or at least that is what i understood what the conditional must was)

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Wed, 16 Jun 2010 16:10:33 -0700

Folks,

I would like to note a subtle difference between a conditional MUST and
a conditional SHOULD.  Although for both MUST and SHOULD, the addition
of a condition limits the applicability of the rule being specified, the
rule will have a different requirements level in those scenarios where
it does apply:

- If we use a conditional MUST, then the rule has to be followed
  provided the added condition renders the rule applicable.

- If we use a conditional SHOULD, then the rule is at most a strong
  recommendation.  There may still be good reasons not to follow the
  rule, even if the the added condition renders the rule applicable.

Consequently, in order to decide whether to use a conditional MUST or a
conditional SHOULD, my question to the working group is the following: 
In scenarios where direct host attachment to the SAVI device cannot be
guaranteed, what requirements level do we want to use for data-packet-
triggered binding creation:  MUST or SHOULD?

- Christian

On Jun 14, 2010, Marcelo Bagnulo Braun wrote:

> An example of what i understand is a conditional MUST can be foudn
> for instance in RFC4862, where it reads:
> 
>   -  An interface whose DupAddrDetectTransmits variable is set to
>      zero does not perform Duplicate Address Detection.
>

---

From: "Bi Jun" <[email-masked]>
Date: Sat, 19 Jun 2010 02:04:23 +0800

--------------------------------------------------
From: "Christian Vogt" <[email-masked]>
Sent: Thursday, June 17, 2010 7:10 AM
To: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] Requirements level for data-packet-triggered 
bindingcreation

> triggered binding creation:  MUST or SHOULD?

Dear WG members,

My answer to this question is "SHOULD".

Thanks,
Jun Bi

---

From: Frank Xia <[email-masked]>
Date: Fri, 18 Jun 2010 11:42:19 -0700

SHOULD

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Vogt
Sent: Wednesday, June 16, 2010 4:11 PM
To: SAVI Mailing List
Subject: Re: [savi] Requirements level for data-packet-triggered
bindingcreation

Folks,

- Christian

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 20 Jun 2010 02:58:02 -0700

> triggered binding creation:  MUST or SHOULD?

According to RFC 2026 the criteria for proposed standard includes "has 
resolved known design choices", and a SHOULD sounds like the WG would 
want to sit on the fence whether or not data triggered binding creation 
is REQUIRED.

Hence I see two choices:
  - a MUST in a Proposed Standard
  - a SHOULD in an Experimental RFC

My personal preference is for the former.

    Erik

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 20 Jun 2010 23:40:36 +0800

Thanks to Erik, but the data-trigger is only a supplement part of savi-dhcp 
solution,
then I don't think it will affect the document type.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Erik Nordmark" <[email-masked]>
Sent: Sunday, June 20, 2010 5:58 PM
To: "Christian Vogt" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] Requirements level for data-packet-triggered binding 
creation

> resolved known design choices", and a SHOULD sounds like the WG would want 
> to sit on the fence whether or not data triggered binding creation is 
> REQUIRED.
>
> Hence I see two choices:

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Jun 2010 11:12:14 -0700

On Jun 20, 2010, Bi Jun wrote:

> solution...

This is not quite correct, Jun.  We have seen that data-packet-triggered binding creation can be a key component to prevent loss of legitimate packets.  In fact, we have seen it to be a key component in all scenarios where direct attachment of hosts to SAVI devices cannot be guaranteed.

- Christian

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 22 Jun 2010 10:13:57 +0800

--------------------------------------------------
From: "Christian Vogt" <[email-masked]>
Sent: Tuesday, June 22, 2010 2:12 AM
To: "Bi Jun" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] Requirements level for data-packet-triggered 
bindingcreation

> This is not quite correct, Jun.  We have seen that data-packet-triggered 
> binding creation can be a key component to prevent loss of legitimate 
> packets.  In fact, we have seen it to be a key component in all scenarios 
> where direct attachment of hosts to SAVI devices cannot be guaranteed.
>

Then may we know if those scenarios are general or not.

Best Regards,
Jun Bi

---

From: Lin Tao <[email-masked]>
Date: Wed, 23 Jun 2010 21:49:33 +0800

+1

LinTao

---

From: Lin Tao <[email-masked]>
Date: Wed, 23 Jun 2010 21:50:39 +0800

Should

Thanks!

LinTao

---

From: Christian Vogt <[email-masked]>
Date: Mon, 28 Jun 2010 11:38:51 -0700

Erik:

Giving implementors two options doesn't necessarily mean that there are
unresolved design issues.  If a clear explanation is provided on each
option's consequences, then the requirements for Proposed Standards are
fulfilled, aren't they?

- Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Jun 2010 00:57:31 -0400

I would agree that "SHOULD" does not mean that there is an unresolved 
design issue.   (Otherwise, lots of IETF specs would be in violation.)

However, the question that concerns me, is what the actual description 
of the condition is.  Possiblities include:
a) Implementations SHOULD support data triggered unless they will never 
be deployed more than one hop from the client device?
b) Implementations should use data triggered behavior unless they know, 
via configuration, that they are adjacent to all client devices they are 
supporting?

The challenge with the particular condition we are trying to describe is 
to know when it applies.  And to write that text clearly.

Yours,
Joel

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Jun 2010 22:33:03 -0700

My rule for using the words - and  I don't call them "conditional", because a SHOULD is already conditional - is:

Something is a MUST if something else will break if we don't do it, unconditionally.
Something is a MAY if some folks in the WG would really like to do something or suggest that folks do something, but can't make a stronger consensus, and
Something is a SHOULD if we would like to say "MUST" but can think of cases where it might not apply.

In general, if a specification calls out a SHOULD and an implementation does not, the implementation is on the hook to say why it didn't.

Anything further, such as "this is a truly important semiconditional MAY", is splitting hairs. Pick one: MUST (and say what breaks), SHOULD, or MAY.

On Jun 28, 2010, at 9:57 PM, Joel M. Halpern wrote:

> I would agree that "SHOULD" does not mean that there is an unresolved design issue.   (Otherwise, lots of IETF specs would be in violation.)
> 
> However, the question that concerns me, is what the actual description of the condition is.  Possiblities include:
> a) Implementations SHOULD support data triggered unless they will never be deployed more than one hop from the client device?
> b) Implementations should use data triggered behavior unless they know, via configuration, that they are adjacent to all client devices they are supporting?
> 
> The challenge with the particular condition we are trying to describe is to know when it applies.  And to write that text clearly.
> 
> Yours,
> Joel
> 
> Christian Vogt wrote:
>> Erik: