Re: [cuss] "isdn-uui" versus "isdn-network"

["Vijay K. Gurbani" <[e-mail]>]

On 11/20/2013 10:51 AM, [e-mail] wrote:
> Vijay,
>
> I don't know who had been invited to the hallway conversation you
> mentioned but to be honest, I'm really surprised by the decision
> made.

Bruno: Rest assured that no one was explicitly invited or implicitly
precluded in the hallway conversation.  Since the chairs, the AD,
the authors and some working group members were physically at the same
space and time in Vancouver, it seemed appropriate to look into what was
holding the draft back.

> Indeed, there were no objections on the cuss list to the latest
> wording (informative) proposed on Sept 12 for the text to be added to
> the document and I don't really understand why the proposal was not
> implemented right away in the I-D actually!
> http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html

As to why the proposal of Sept 12 was not implemented in the draft
right away, I will have to defer to the author, but my understanding,
as you write below, is that there was enough of a gray area that
the authors did not quite know how to proceed.

> Moreover, all people who have been active on this topic on the cuss
> mailing list either supported the addition of an informative text or
> have asked questions for clarification. I have not seen any explicit
> objection.
>
> So, how can a hallway conversation lead to such a U-turn?

The seeming U-turn stems from the fact that either the note being added
be normative or informative.  If informative, then then this note sets a
precedence that parameters defined in Work In Progress Internet-Drafts
be supported in perpetuity.  If normative, then the ABNF has to be
updated and all implementations must not bear the burden of
allocating the same semantic meaning to two syntactically different
headers.  This just seems bad protocol design.

The expedient thing was to take a position and go with WGLC on the
understanding that if the position is not preferable, then this will
be hashed on the mailing list (essentially what we are doing now).

That said, I will take my chair hat off and address what you write
next as an individual contributor.

> Furthermore, I'd like to understand why people have concerns with
> adding the proposed informative statement in the CUSS document but
> seem to be happy with a similar note in
> draft-ietf-bfcpbis-rfc4583bis
>
> Note: In [15] 'm-stream' was erroneously used in Section 10.
> Although the example was non-normative, it is implemented by some
> vendors and occurs in cases where the endpoint is willing to act as
> an server.  Therefore, it is RECOMMENDED to support parsing and
> interpreting 'm-stream' the same way as 'mstrm' when receiving.

I have no idea why the bfcpbis working group agreed to alias 'm-stream'
to 'mstrm', but it is certainly their prerogative.  However, does that
mean that we do the same in cuss working group?  Alias header names
just mean that implementations have to add more parsing machinery
to handle the same outcome for a parsed token. Having written a SIP
parser, I am all for making SIP parsing as much deterministic as
possible.

My personal (i.e., not as chair) preference is to have one header name.

Now, back to my role as a chair.

If you'd like to maintain "isdn-network" as an alias for "isdn-uui",
then we need to seek consensus on the list with the understanding that
the note moves to normative and the ABNF is updated to reflect the
alias.  We cannot straddle the fence and simply put a note allowing
"isdn-network" without modifying the ABNF, etc.  This must be done for
the draft to proceed to IESG.

The draft is now in WGLC, and we can certainly handle this change if
the working group agrees as an outcome of WGLC.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq