Re: New Version Notification for draft-bryant-rtgwg-param-sync-01.txt

[t.petch <[e-mail]>]

----- Original Message -----
From: "Stewart Bryant" <[e-mail]>
Sent: Tuesday, February 28, 2017 7:19 PM
> On 28/02/2017 17:20, t.petch wrote:
> > ----- Original Message -----
> > From: "Stewart Bryant" <[e-mail]>
> > Sent: Tuesday, February 28, 2017 11:48 AM
> >
> >> Hi Tom
> >>
> >> The intent is clear in the rest of the text.
> >>
> >> This was an oversight in the editing.
> >>
> >> How about "Network Wide Routing Parameter Registry"?
> > Stewart
> >
> > I would like it to start with 'Routing ...' since that makes it
appear
> > where I expect to find it in the (flat and very long) IANA parameter
> > list.
> >
> > Routing Parameter Network Wide Registry perhaps
> >
> > Clumsier I know but I am attached to an initial Routing which
collates
> > it alongside RIP, RPL and such like.
>
> Horribly clumsy! It does not scan at all.
>
> Maybe Routing Parameter Synchronization Registry?
>
> ... but isn't this in the weeds when we are still at the adoption
stag?


Weelll I am thinking ahead to what might come next:-)

I see MPLS as a good example of how not to think ahead and set up an
IANA registry that then costs a lot of time and effort to put right at a
later date.  Yes, that is how the IETF does things but it is still a
waste of scarce resources.

My first thought on seeing the registry name was that it was misleading
and yes, you agree to change it.  My second thought was that there must
be a 'Routing ...' Group in IANA under which your original name would be
fine since the Gropu name would limit the scope.  But no, I see no sign
of a 'Routing ..' Group so perhaps now is the time to create one.

I do support adoption of the I-D by the way.

Tom Petch

> - Stewart
>
>
>
> >
> > Tom Petch
> >
> >> - Stewart
> >>
> >> On 28/02/2017 10:54, t.petch wrote:
> >>> Stewart
> >>>
> >>> You say that this protocol is only intended to be used for the
> >>> propagation of
> >>> parameters needed to support the operation of the routing system
but
> > the
> >>> registry you create is named
> >>> Network Wide Parameter Registry
> >>> which to me still carries the message that this is all embracing,
> > not
> >>> just for routing.
> >>>
> >>> Tom Petch
> >>>
> >>> ----- Original Message -----
> >>> From: "Stewart Bryant" <[e-mail]>
> >>> Sent: Monday, February 27, 2017 5:23 PM
> >>>
> >>>> Resend with correct ISIS WG email address
> >>>>
> >>>> Following discussion at the last IETF, I have made a number
> >>>> of changes to the text to emphasis that this protocols
> >>>> is only to be used for the synchronization of parameters needs
> >>>> by the routing system.
> >>>>
> >>>> As agreed at the RTGWG meeting I am notifying RTGWG, ISIS and
OSPF
> >>> WGs.
> >>>> The draft can be found here:
> >>>>
> >>>> URL:
> >>>>
> >
https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-sync-01.tx
> >>> t
> >>>> Status:
> >>>> https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/
> >>>> Htmlized:
> >>> https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-01
> >>>> Diff:
> >>>>
https://www.ietf.org/rfcdiff?url2=draft-bryant-rtgwg-param-sync-01
> >>>>
> >>>> The following is a summary of the changed:
> >>>>
> >>>> I have changed the title to:
> >>>>
> >>>> Synchronisation of Routing Parameters
> >>>>
> >>>> =========
> >>>>
> >>>> I have added in the introduction:
> >>>>
> >>>> Note that this protocol is only intended to be used for the
> >>> propagation of
> >>>> parameters needed to support the operation of the routing system.
> > It
> >>>> MUST NOT
> >>>> be used as a general purpose parameter exchange protocol, and in
> >>>> particular it
> >>>> MUST NOT be used as a parameter negotiation protocol, since such
> > use
> >>> may
> >>>> degrade the ability of the underlying link-state routing protocol
> > to
> >>>> carry our
> >>>> its essential purpose.
> >>>>
> >>>> ========
> >>>>
> >>>> I have changed the IANA text to say:
> >>>>
> >>>> Synchronisation of Routing Parameters
> >>>>
> >>>> ========
> >>>>
> >>>> I have added to the security section:
> >>>>
> >>>> In specifying a new parameter, consideration must be given
> >>>> to the impact of the additional parameter, and in particular the
> >>>> rate of change of that parameter, on the dynamics of the
link-state
> >>>> routing protocol in use. In the specific case of the
> >>>> Convergence Timer, the amount of data being carried and the
> >>>> rate of change of the parameter value will have a negligible
> >>>> impact on the link-state routing protocol in use.
> >>>>
> >>>> =========
> >>>>
> >>>> Incorporated a number of review suggestions by Mohamed Boucadair
> > (Mod)
> >>>> Added
> >>>>
> >>>> Such consistency may be ensured by deploying automated
> >>>> means such as enforcing the new value by invoking the
> >>>> management interface of all involved routers. For example,
> >>>> a central management entity may be responsible for
> >>>> communicating the new configuration value by means of
> >>>> vendor-specific CLI, NETCONF, etc. This approach may be
> >>>> attracting if all involved nodes expose technology-agnostic
> >>>> and vendor-independent interfaces to tweak a given network-wide
> >>>> configuration parameter.
> >>>>
> >>>> ======
> >>>>
> >>>> I would like to propose that we move this forward to become a WG
> > draft
> >>>> and refine the detail under the WG process.
> >>>>
> >>>> - Stewart
> >>>>
> >>>> _______________________________________________
> >>>> rtgwg mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/rtgwg
>