RE: Evaluation: draft-ietf-ccamp-gmpls-sonet-sdh - Generalized Mu ltiprotocol Label Switching Extensions for SONET and SDH Control to Prop o sed Standard

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Allison, I have not yet seen a response to this one.

My understanding is that Steve has now cleared his discuss.
Since I am sensistive to your concerns, I'd like to do due
dilligence and make sure you're OK with the doc before I
push forward. But pls... do then answer my quesitons or
tell me to go ahead. This has been "in DISCUSS" mode too long
without an actual write-up of any issue. That is not helping
our image in the perception of the WG.

Thanks,
Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: donderdag 27 maart 2003 3:14
> To: Allison Mankin
> Cc: Steven M. Bellovin; iesg@ietf.org
> Subject: RE: Evaluation: draft-ietf-ccamp-gmpls-sonet-sdh - 
> Generalized
> Mu ltiprotocol Label Switching Extensions for SONET and SDH Control to
> Prop o sed Standard 
> 
> 
> Inline
> 
> > -----Original Message-----
> > From: Allison Mankin [mailto:mankin@psg.com]
> > Sent: woensdag 26 maart 2003 20:05
> > To: Wijnen, Bert (Bert)
> > Cc: Steven M. Bellovin; iesg@ietf.org
> > Subject: Re: Evaluation: draft-ietf-ccamp-gmpls-sonet-sdh - 
> > Generalized
> > Mu ltiprotocol Label Switching Extensions for SONET and SDH 
> Control to
> > Prop o sed Standard 
> > 
> > 
> > > 
> > > I thought Allison worried about the security, but I don't think
> > > she had specific issues and was hoping/asking you for a serious
> > > check. So if you do not see issues, then I would assume all
> > > will be OK with this doc.
> > 
> > Steve,
> > 
> > The questions were:
> > 
> > 1. how weak were the antecedents, since it only points to 
> them rather
> >    than having any security considerations itself?
> > 
> > 2. might this document deserve a stronger consideration 
> than the base
> >    technology, because the payload is particularly sensitive, 
> >    the way we 
> >    consider that ISUP is, and we treat SIGTRAN and SIP-T 
> >    documents with more stringent security considerations?
> > 
> > 1. I checked GMPLS-RSVP-TE, which I think is the most important
> >    antecedent, and it is not weak.  The text says it was worked
> >    on a lot by SMB,  in fact...anyway,
> 
> Right, SMB DID push back on that earlier RFC a lot and ended
> up helping them to write the section.
> 
> >    I'm no longer worried on the antecedent score...
> > 
> Great
> 
> > It does have a great typo :)
> > 
> >          Messages MUST NOT be accepted except from nodes 
> that are not
> >          known to the recipient to be authorized to make 
> such requests.
> > 
> Do you mean: s/are not/are/
> You may want to report this for the RFC-Errata page.
> 
> > 2. Judgement call.  I raise my question because I only made 
> > it spoken and maybe it wasn't a good question or clear?
> > 
> So why do you think this is particularly more sensitive than the base
> GMPLS materials?
> 
> Bert
> > Allison
> > 
> > > 
> > > > -----Original Message-----
> > > > From: Steven M. Bellovin [mailto:smb@research.att.com]
> > > > Sent: woensdag 26 maart 2003 5:56
> > > > To: Wijnen, Bert (Bert)
> > > > Cc: iesg@ietf.org
> > > > Subject: Re: Evaluation: draft-ietf-ccamp-gmpls-sonet-sdh - 
> > > > Generalized
> > > > Mu ltiprotocol Label Switching Extensions for SONET and 
> > SDH Control to
> > > > Prop o sed Standard 
> > > > 
> > > > 
> > > > In message 
> > > > 
> > <7D5D48D2CAA3D84C813F5B154F43B1550115755E@nl0006exch001u.nl.lucent.c
> > > > om>, "Wijnen, Bert (Bert)" writes:
> > > > >Steve, you are holding a DISCUSS that you still have to 
> > > > >either write-up or give up. Below the pointers I gave you.
> > > > >
> > > > >The abllot:
> > > > >http://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ccamp-gmpls-s
> > > > onet-sdh.bal
> > > > >
> > > > >Do you think you can find the time to at least get me a writeup
> > > > >so that I can get the authors some feedback as to why their
> > > > >document was not approved. They have asked me a few times
> > > > >already.
> > > > 
> > > > I just reread the spec.  From the little I understood, I see no
> > > > security issue in it.  There may be a problem with the base 
> > > > GMPLS specs,
> > > > but I didn't go back to those; in any event, it seems 
> > inappropriate to
> > > > block this relatively-innocuous document because of 
> > concerns about the
> > > > base spec.  I wasn't the one who raised the initial 
> > concern about this
> > > > document, so I don't remember what the base issue may 
> > have been; does
> > > > anyone else have anything specific to point to?  If not, 
> > I'm going to
> > > > clear my DISCUSS.  (My apologies if I sound a bit grumpy.  
> > > > I'm not only
> > > > seriously short on sleep, I'm on a train that has been 
> > > > stalled (with no
> > > > progress in sight) for the last 100 (U.S.) minutes because of 
> > > > "a fatality
> > > > on the tracks".  The lights are off, the ventilation is off, 
> > > > laptop power
> > > > is off, and I don't have a wireless modem that will let me
> > > > get to the ballot web site.)
> > > > 
> >  
> > 
>