Subject: Re: Fwd: (ngtrans) diff-serv comments on transition mechanisms spec

From: Erik Nordmark <[email-masked]>
Date: Thu, 6 May 1999 20:29:42 -0700 (PDT)

> I usually seem to be on the wrong frequency about "normative
> references", but here's my 2 ore worth: Just declare that the
> handling of the TOS/Precedence/Traffic Class fields are undefined in
> your document.  Then (a) implementation of your spec is possible
> without reference to diff-serv, and (b) implementation of a diff-serv
> PS will not conflict.

And what should the implementor do?
Isn't the protocol spec supposed to at least provide some guidance on how
to implement the protocol?

   Erik

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 07 May 1999 08:39:35 -0500

> > ... Just declare that the handling of the TOS/Precedence/Traffic
> > Class fields are undefined in your document.  ...
> 
> And what should the implementor do?  Isn't the protocol spec
> supposed to at least provide some guidance on how to implement the
> protocol?

The claim is (or would be) that those bits aren't part of this
protocol.  The IETF as a whole as an approximate 0% success rate at
defining the treatment of the field under discussion, so I'm saying
let's leave it completely in the hands of those who currently "own"
that problem.

An implementation would then be compliant with the transition
mechanism spec regardless of what it did with that field.  No doubt
the implementator will also want to comply with some diff-serv spec,
which will tell it how to handle the Traffic Class field.  It's just
a simple matter of orthogonality, isn't it?

			Matt

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 May 1999 16:58:28 +0100

I do think that leaving it explicitly undefined is less bad than
defining it to be forced to zero. It avoids having to
remember this dependency in future.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
As of May 24, 1999: on assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 May 1999 17:22:31 -0700 (PDT)

> remember this dependency in future.

I think it makes sense to add some vague reference to future/ongoing work
for the TOS bits in the document - just as a heads up for the implementors.

But there would still need to be a future standards track RFC that describes 
how to handle all these bits that apply to different forms of tunneling 
(v4 over v4, v6 over v4, etc). Thus I don't see how you can avoid to
one way or another (implicitly or explicitly) update the various tunnel
specifications.

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 May 1999 10:42:52 +0100

> one way or another (implicitly or explicitly) update the various tunnel

True; all I am asking for is a few words that flag the
issue without creating a document-dependency loop.