Subject: Re: [netmod] AD review of draft-linowski-netmod-yang-abstract-04

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 Dec 2010 18:09:06 +0100

These look OK to me. 

Please make sure that the explanations that you provided on T2 and T3
get clarified in text. 

Dan

> -----Original Message-----
> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]] 
> Sent: Friday, November 26, 2010 12:34 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; Linowski, Bernd 
> (EXT-Other - DE)
> Subject: RE: AD review of draft-linowski-netmod-yang-abstract-04
> 
> Hi Dan,
> 
> please find below our attempt to fix the issues you raised.
> 
> Mehmet
> 
> 
> > -----Original Message-----
> > From: ext Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Thursday, November 04, 2010 11:34 AM
> > To: [email-masked]; Ersue, 
> Mehmet (NSN - 
> > DE/Munich); [email-masked]
> > Cc: [email-masked]
> > Subject: AD review of draft-linowski-netmod-yang-abstract-04
> > 
> > I have reviewed draft-linowski-netmod-yang-abstract-04. I 
> think that 
> > this document is in good shape and I will proceed to sending it to
> IETF
> > Last Call. Please consider the comments below together with 
> other IETF 
> > Last Call comments.
> > 
> > The comments are marked with T for Technical and E for Editorial.
> > 
> > 
> > T1. As the intended status is Experimental, I believe that 
> it would be 
> > useful to add in the introduction some text that describes 
> the purpose 
> > of the experiment, and the fact that the language 
> extensions described 
> > in this document may become (if the experimental usage succeeds)
> either
> > a proposed standard or part of a future version of NETCONF.
> 
> We agree, we should add a sentence into the introduction 
> section stating, e.g.: 
> "After successful usage this experimental specification can 
> be republished at IETF either as a proposed standard or as 
> part of a future version of YANG."
>  
> > T2. section 2.10 -  I do not understand the concept of 
> equimentHolder
> -
> > is it the same as the vendor or manufacturer of a physical 
> entity? Why 
> > is it called differently?
> 
> The idea of making a distinction between "Equipment" and 
> "EquipmentHolders"
> was taken over from SID. To my understanding, an equipment 
> holder is a piece of equipment with the primary purpose of 
> containing other equipment.
> The description in SID V8 says:
> "This class is based on the M.3100 specification, and is a 
> base class that represents physical objects that are both 
> manageable as well as able to host, hold, or contain other 
> physical objects.
> Examples of physical objects that can be represented by 
> instances of this object class are Racks, Chassis, Cards, and Slots."
>  
> > T3. In the example in section 3.3
> > 
> > <serialNumeber>F-7786828</serialNumber>
> > 
> > What does a serial number mean for a physical link?
> 
> "serial number" could be the part number of a fiber link cable. 
> The SID describes serial number as "manufacturer-allocated 
> part number", so in some cases this might also apply to 
> physical links.
>  
> > 
> > T4. In the IANA considerations section:
> > 
> > > Registrant Contact: The NETMOD WG of the IETF.
> > 
> > This is not a WG document. Did the WG formally agree to 
> take upon this 
> > role?
> 
> We will note the document authors as Registrant Contact.
>  
> > E1. idnits complains:
> > 
> >  == Unused Reference: 'RFC5226' is defined on line 1364, but no 
> > explicit reference was found in the text
> 
> The reference will be deleted.
>  
> > E2. It would be good to mention explicitly relative to what are 
> > referred the 'improvements' described in section 1.3
> 
> We will note in section 1.3 that the improvements are 
> compared to languages without language abstractions.
>  
> > E3. I suggest that you reorder appendices and make the 
> change log the 
> > last one - paying attention to make changes in the places where the 
> > other appendices are referred in the text. As the change 
> log will be 
> > taken out of the final version (I assume) this can avoid
> complications.
> 
> OK.
>  
> > E4. Section 1.5.1:
> > 
> > >    It is
> >       important to notice that this kind of relationships do not 
> > mandate
> >       any particular location of the two connected hardware 
> instances 
> > in
> >       any MIB.
> > 
> > Clarify what 'MIB' means here - MIB module, instance of MIB module?
> 
> It was meant to be the instances of a MIB module.
>  
> > E5. T3. In the example in section 3.3
> > 
> > <serialNumeber>F-7786828</serialNumber>
> > 
> > s/serialNumeber/serial/Number/
> 
> Thanks for the hint.
>  
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> 
>