Re: [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04

[<[e-mail]>]

Re-,

I agree with you that many tunneling schemes are not present in the IANA registry but is that a problem? I don't think so because registrations are for a reason. 

The natural way from where I sit is that any specification that, for example, defines a specific YANG module for a tunneling scheme not currently in the IANA registry, and needs a specific interface type, will make a request for a code assignment.

FWIW, we are making this work because we had a concrete case (draft-ietf-softwire-yang) which needs to augment the YANG interface module for a specific tunnel scheme. To that aim, we requested IANA to assign a new type and designed this module to access to tunnel types maintained by IANA.

When a new registration is made, the module defined in draft-ietf-softwire-iftunnel will be updated automatically by IANA.  

I fail to see why the "best course of action" for this document is to register new types without defining the usage.  

Cheers,
Med

> -----Message d'origine-----
> De : Black, David [mailto:[e-mail]]
> Envoyé : jeudi 9 mai 2019 15:46
> À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
> Cc : [e-mail]; [e-mail]; draft-ietf-softwire-
> [e-mail]; Black, David
> Objet : RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> > [Med] The intent of the draft is to reflect the current registered
> tunnels types.
> ...
> > [Med] Registering new tunnel types is not in the scope set for this
> draft.
> 
> I understand that, but as stated in the review, I don't think that it's
> the best course of action.  The email below appears to reject all of the
> IETF Last Call comments in the review and in particular presents the scope
> of the draft as fixed and unchangeable; that's unfortunate.  On that
> basis, I will agree to disagree and leave these IETF Last Call concerns to
> the ADs to sort out.
> 
> Thanks, --David
> 
> > -----Original Message-----
> > From: [e-mail]
> > <[e-mail]>
> > Sent: Thursday, May 9, 2019 3:50 AM
> > To: Black, David; [e-mail]
> > Cc: [e-mail]; [e-mail]; draft-ietf-softwire-
> [e-mail]
> > Subject: RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Hi David,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : David Black via Datatracker [mailto:[e-mail]]
> > > Envoyé : mercredi 8 mai 2019 00:46
> > > À : [e-mail]
> > > Cc : [e-mail]; [e-mail]; draft-ietf-softwire-
> > > [e-mail]
> > > Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> > >
> > > Reviewer: David Black
> > > Review result: Not Ready
> > >
> > > This document has been reviewed as part of the transport area review
> > team's
> > > ongoing effort to review key IETF documents. These comments were
> > written
> > > primarily for the transport area directors, but are copied to the
> document's
> > > authors and WG to allow them to address any issues raised and also to
> the
> > > IETF discussion list for information.
> > >
> > > When done at the time of IETF Last Call, the authors should consider
> this
> > > review as part of the last-call comments they receive. Please always
> CC
> > > [e-mail] if you reply to or forward this review.
> > >
> > > This draft defines a YANG module for tunnel types based on the MIB-2
> > > tunnel type registry maintained by IANA.
> > >
> > > My fundamental concern with this draft is that the MIB-2 tunnel type
> > > registry is seriously incomplete and out of date, as there are a large
> > > number of tunnel types that aren't included in that registry, e.g.,
> IPsec
> > > tunnel-mode AMT tunneling.  In its current form, that registry does
> not
> > > appear to be a good starting point for specifying YANG management of
> > > tunnels.
> > >
> > > A limited justification that I could envision for defining this YANG
> module
> > > would be to use it for mechanical translations to YANG of existing
> MIBs
> > > that use MIB-2 tunnel types - if that's the justification, then it
> would need
> > > to be clearly stated in an applicability statement within this draft,
> >
> > [Med] The intent of the draft is to reflect the current registered
> tunnels
> > types. This is mentioned in the introduction:
> >
> >    This document specifies the initial version of the iana-tunnel-type
> >                                ^^^^^^^^^^^^^^
> >    YANG module identifying tunnel interface types.  The module reflects
> >                                                                ^^^^^^^^
> >    IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY].  The latest
> >    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >    revision of this module can be obtained from the IANA web site.
> >
> >  and the
> > > discussion of extension of this YANG module would need to be aligned
> > with
> > > that limited applicability.
> >
> > [Med] This is an IANA-maintained module. That is, when a new tunnel type
> is
> > registered, the module will be automatically updated to include that new
> > type identity:
> >
> >       When this registry is modified, the YANG module iana-tunnel-type
> >       must be updated as defined in RFCXXXX.
> >
> > >
> > > The proverbial "right thing to do" would be to update both the MIB-2
> > tunnel
> > > type registry and this draft with all of the currently known tunnel
> types.
> >
> > [Med] Registering new tunnel types is not in the scope set for this
> draft. It is
> > up to the documents defining these tunnel types or making use of them to
> > make a request to IANA. For example, this is the approach followed in
> > softwire wg for at least three tunnel types (16, 17, 18).
> >
> > > The references section of draft-ietf-tsvwg-rfc6040update-shim
> > > (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-
> shim/)
> > > may help in identifying tunnel protocols that should be included.
> > >
> > > A minor concern involves the use of RFC 8085 as the reference for UDP
> > > tunnels; while that's certainly better than the existing use of RFC
> 4087, due
> > > to the extensive design guidance in RFC 8085, designers of UDP-
> > encapsulated
> > > tunnel protocols ought to be encouraged to register their protocols as
> > > separate
> > > tunnel types (e.g., so the network operator has some idea of what the
> UDP
> > > tunnel is actually being used for).  This draft ought to encourage
> tunnel
> > > protocol designers to register their own tunnel types in preference to
> > reuse
> > > of the UDP tunnel type, including placing text in the IANA tunnel type
> > > registry and this YANG module to encourage that course of action.
> > >
> >
> > [Med] Wouldn't that recommendation be better added to documents such
> > as: https://tools.ietf.org/html/draft-thaler-iftype-reg-02?